Gateway Architecture: Unified vs BFF vs Hierarchical Topology

Choosing gateway topology involves fundamental tradeoffs between operational simplicity, blast radius, and team autonomy. A unified gateway runs one logical entry point per domain with shared routing and policy. This is cheapest and simplest operationally but creates the highest blast radius risk where a single bug or configuration error affects all clients simultaneously. The unified approach works well for small to medium systems (under 50 services, single client type) but becomes a god gateway bottleneck as the system grows.

Backend for Frontend (BFF) deploys separate gateways per client experience: one for mobile, one for web, one for partner APIs. Each BFF owns its route surface, aggregation logic, and experiments allowing mobile teams to optimize for 300 millisecond p95 cellular budgets with aggressive caching while web teams prioritize real time updates. Netflix uses device specific BFFs where mobile, web, and TV clients each hit different gateway clusters. The tradeoff is duplicating authentication, rate limiting, and observability logic across BFFs though this can be mitigated with shared libraries or control planes.

Hierarchical topology places a thin front door gateway handling TLS termination, WAF, coarse routing, and global rate limits, then fans out to team owned service gateways. For example, an e-commerce front door routes slash users to the user team gateway and slash orders to the order team gateway. Each team gateway implements domain specific aggregation, caching, and fine grained policies. This maximizes team autonomy and reduces blast radius at the cost of an extra network hop (1 to 3 milliseconds in region) and more control planes to manage.

Capacity planning varies significantly. A unified gateway might run 10 to 30 instances per region handling 50,000 requests per second total. BFF topology might run 5 mobile gateway instances plus 8 web gateway instances with different autoscaling triggers. Hierarchical requires front door capacity plus per team gateway capacity. Test scaling to 100,000 plus requests per second with realistic payloads and header sizes since most managed gateways have conservative limits (8 to 16 kilobyte headers, 10 megabyte payloads). Pre warm capacity before expected traffic peaks and model retry amplification where one backend slowdown can triple effective load.

💡 Key Takeaways

•Unified gateway is cheapest and simplest (one control plane) but highest blast radius where single configuration error affects all traffic simultaneously

•Backend for Frontend (BFF) separates by client: mobile BFF optimizes for 300 millisecond p95 cellular budget with aggressive caching while web BFF prioritizes real time

•Hierarchical topology adds extra hop (1 to 3 milliseconds in region) but maximizes team autonomy with front door handling TLS and WAF then routing to team owned service gateways

•Capacity planning example: unified runs 10 to 30 instances handling 50,000 requests per second versus BFF running 5 mobile plus 8 web instances with different autoscaling

•Most managed gateways enforce 8 to 16 kilobyte header limits and 10 megabyte payload limits requiring offload of large uploads to object storage with pre signed URLs

•Pre warm capacity before traffic peaks and model retry amplification where backend slowdown triples effective load requiring 3x gateway capacity during incidents

📌 Examples

Startup with single mobile app uses unified gateway running 5 instances handling 5000 requests per second, simplest and cheapest at $300 per month

Netflix deploys separate BFFs: mobile gateway aggregates 5 calls into one for offline sync, TV gateway pre fetches next episode metadata, web gateway returns full JSON for client rendering

Large e-commerce runs hierarchical: front door at 100K requests per second routes to user gateway (20K requests per second), order gateway (30K requests per second), search gateway (50K requests per second)

← Back to API Gateway Patterns Overview