API Gateway Patterns

The API gateway sits between external consumers and internal services. It is the single entry point that handles cross-cutting concerns — authentication, rate limiting, routing, protocol translation — so that individual services do not need to. The gateway is a load-bearing component. Its design determines the developer experience for external consumers and the operational complexity for the team.

1. Backend for Frontend (BFF) A dedicated gateway per client type: one for the web application, one for the mobile app, one for third-party integrations. Each BFF is tailored to its consumer's needs — the mobile BFF returns smaller payloads, the web BFF supports server-side rendering, the integration BFF provides stable versioned endpoints. The trade-off: more gateways to maintain. The benefit: each consumer gets an optimized experience.
2. Aggregation Gateway The gateway composes responses from multiple services into a single API response. The client requests "order details" and the gateway calls the order service, the customer service, and the shipping service, then assembles the response. The client makes one call instead of three. The trade-off: the gateway contains composition logic that must be maintained as services evolve.
3. Thin Routing Gateway The gateway does routing and cross-cutting concerns only — no aggregation, no transformation, no business logic. It authenticates the request, applies rate limits, and forwards to the correct service. The trade-off: the client may need multiple calls. The benefit: the gateway is simple, stateless, and easy to operate. This is usually the right starting point.