Quick Answer
The right API gateway pattern depends on where complexity belongs: at the client boundary, in shared platform controls, or between internal services. Use backend-for-frontend for meaningfully different client experiences, aggregation for reducing chatty client calls, and offloading only for stable cross-cutting policies such as authentication, routing, and rate limiting.
Introduction
An API gateway should simplify client access to a microservices architecture, not become a second application tier with opaque business logic. Teams often adopt a gateway because service count is growing, then overload it with orchestration that should remain in domain services. The result is a central bottleneck that is difficult to test, deploy, and own. The boundary is clear: gateways handle edge concerns, while services retain domain decisions and data ownership.
Key Takeaways:
Use gateway patterns to reduce boundary complexity, not to centralize business logic.
Separate north-south API traffic from service-to-service communication requirements.
Measure latency and operational ownership before adding gateway plugins or orchestration.
API gateway design patterns
Gateway design starts with request shape, not a vendor shortlist. A mobile app, web dashboard, partner integration, and internal automation client may need different responses, but they should not force every downstream service to expose client-specific endpoints. Good communication patterns for microservices keep synchronous client traffic narrow and make internal workflows explicit.
Choose a pattern based on the work performed at the edge and the client boundary
Three patterns solve different problems: aggregation composes data, offloading centralizes repeatable infrastructure policy, and backend-for-frontend tailors an interface for a specific client. Treating them as interchangeable creates a gateway that owns too much application behavior.
Aggregation: Combines several service responses into one client response.
Offloading: Centralizes authentication, routing, logging, and request policy.
Backend-for-frontend: Serves one client type with its own API contract.
Pass-through: Routes requests without composing business data.
Aggregation is useful only when it removes real client round trips
Gateway aggregation earns its cost when a screen requires data from several bounded contexts and the client would otherwise coordinate multiple calls. It should compose stable read models, apply response shaping, and fail predictably when a noncritical dependency is unavailable. Do not use it to coordinate writes across services, because retries, partial failures, and compensating actions quickly turn a request router into a workflow engine.
The API gateway pattern also reduces exposure by keeping internal microservices out of the public boundary. Microsoft notes that, without a gateway, client applications must send requests directly to microservices, exposing more services to the external world and expanding the attack surface.
API gateway vs reverse proxy and service mesh: assign each layer one job
An API gateway, reverse proxy, and service mesh can all route traffic, but they solve different scopes of the distributed systems problem. Conflating them produces duplicated authentication, overlapping retry behavior, and debugging paths that no team can explain during an incident. These are trade-offs in system design, not interchangeable infrastructure labels.
Compare the request boundary before selecting tooling
A reverse proxy focuses on forwarding and termination at a network boundary. An API gateway adds API-aware controls such as consumer authentication, request transformation, and product-level rate policies. A service mesh governs east-west workload traffic and requires a more invasive deployment model because a data-plane proxy runs alongside every service replica. A service mesh typically manages service-to-service traffic through workload-level proxies and policy.
The table separates the operational responsibilities that teams should keep distinct.
Layer | Primary traffic | Typical responsibility | Operational cost |
|---|---|---|---|
Reverse proxy | Inbound HTTP traffic | Forwarding, TLS termination, basic routing | Central configuration and edge availability |
API gateway | Client-to-service traffic | Authentication, rate limits, API routing, response shaping, version routing | Policy ownership and gateway capacity planning |
Service mesh | Service-to-service traffic | Workload identity, mutual TLS, tracing, traffic policy | Proxy deployment beside every service replica |
Use a gateway for north-south traffic and a mesh only when east-west consistency justifies its deployment and CI/CD footprint. A 2025 API gateway versus service mesh guide frames the same north-south and east-west distinction, and notes that overlapping functionality around resilience and observability is a common source of confusion between the two layers. That flexibility does not eliminate a mesh's operational burden.
Backend-for-frontend prevents generic APIs from serving nobody well
Backend-for-frontend is the right pattern when client types have durable differences in data shape, release cadence, or interaction flow. A mobile client may need compact payloads and staged loading, while an operations console may require richer filters and administrative actions. Build separate client-facing adapters, but keep shared domain logic in downstream services and apply sound API design practices so contracts remain explicit.
Do not create a BFF for every frontend repository. If two clients call the same resources with the same authorization model and response shape, one gateway contract is easier to govern than parallel adapters with duplicated behavior.
Build a gateway layer that remains observable under load
Gateway capacity is an engineering constraint, not a configuration detail. Every plugin, token validation, transformation, upstream retry, and aggregation call adds latency and failure modes to the request path. Teams need a load profile before deciding whether a simple reverse proxy configuration is enough or an API-aware gateway is justified. Gateway capabilities vary by product and deployment model; evaluate routing, versioning, and release controls against the operational requirements of the platform.
Make performance and resilience visible before production traffic does
Start with representative routes: anonymous reads, authenticated writes, large responses, slow dependencies, and bursty clients. Track gateway latency separately from upstream latency, then enforce timeout budgets that leave room for the gateway to return a controlled error. For a reference point, Kong's published benchmark results are updated for each Kong Gateway minor release and include the test methodology, with throughput figures in the hundreds of thousands of requests per second under its basic test configuration; plugin mix, hardware, payload shape, and upstream behavior still determine real deployment results.
Optimizing API gateway performance is mostly a matter of restraint. Cache safe reads near the edge, cap request sizes, avoid synchronous fan-out across many services, and never let retries amplify a failing upstream dependency. When a gateway must serve high traffic, keep request-path work bounded and avoid long-running coordination.
Centralize policy, not application ownership
Centralized API gateway authentication layers make policy consistent, especially when clients span browsers, mobile applications, and partner integrations. Validate credentials at the boundary, pass verified identity context downstream, and retain service-level authorization for resource decisions. This division aligns with the challenges of distributed systems: a gateway can identify a caller, but only the service that owns the resource can reliably decide what that caller may do.
Kong and NGINX fit into this decision as gateway-capable tooling rather than architectural answers. Evaluate routing requirements, policy extensibility, deployment model, observability integration, and operational ownership before committing; feature and pricing details vary by product edition and are not interchangeable. Microsoft notes that gateway products can offload cross-cutting functionality from individual microservices into one tier, simplifying each service when those concerns are genuinely shared.
Conclusion
Choose aggregation when it removes client coordination, offloading when a policy is genuinely shared, and backend-for-frontend when client differences are durable. Keep domain workflows out of the gateway, reserve service meshes for east-west controls, and test latency with the plugins and upstream behavior that production will actually use. For teams mapping these choices onto real services, DevvPro provides practitioner-focused analysis of the architectural patterns and decisions that compound over time. The durable gateway is boring at the edge and disciplined about what it refuses to own.
Want a sharper framework for your next platform decision? Explore DevvPro's engineering guides for practical architecture reasoning.
Frequently Asked Questions (FAQs)
What is an API gateway and why do you need one?
An API gateway is a client-facing entry layer that routes requests to services and can apply shared controls such as authentication, rate limiting, and observability, which reduces the need to expose every internal service directly to external clients.
How does an API gateway improve microservices security?
An API gateway improves microservices security by concentrating boundary authentication and request policy in one controlled layer while allowing internal services to remain unexposed, though each service must still enforce authorization for the resources it owns.
Can an API gateway handle rate limiting?
An API gateway can handle rate limiting because it observes client traffic before requests reach upstream services, allowing teams to apply policies by consumer identity, route, credential, or request characteristics without duplicating that logic across services.
Is an API gateway necessary for small applications?
An API gateway is not necessary for small applications when a simple reverse proxy and a small number of well-defined services meet the traffic, security, and routing requirements without adding another deployment unit and ownership surface.
What is the difference between an API gateway and a proxy?
The difference between an API gateway and a proxy is that a proxy primarily forwards traffic at the network boundary, while a gateway is designed to apply API-specific policies such as consumer authentication, routing rules, response transformation, and rate controls.
How to architect a resilient API gateway layer?
Architect a resilient API gateway layer by using multiple instances, explicit timeout budgets, bounded retries, health-aware routing, separate monitoring for gateway and upstream latency, and graceful degradation for optional aggregation dependencies rather than treating every downstream call as mandatory.
What are the trade-offs of using an API gateway?
The trade-offs of using an API gateway include a smaller public attack surface and centralized policy control in exchange for another critical deployment component, potential latency from processing and aggregation, and the risk of creating a monolith if domain logic moves into the gateway.
About the Author
Marcus Rhee is a Developer Advocate and Tech Strategist focused on developer tools, API design, SaaS architecture, and software-driven business models. His work connects implementation details such as routing, identity, and observability with the operational decisions that shape long-term platform velocity.