API Gateway Patterns
You have 12 microservices. Every mobile client talks to all 12. Each service handles its own auth, its own rate limiting, its own CORS. Adding a 13th service means updating every client app. The gateway pattern fixes that.
What a Gateway Does#
An API gateway sits between clients and your services. Clients make one call. The gateway routes it, authenticates the caller, applies rate limits, then proxies to the right service. From the client’s perspective, there’s one endpoint. From the services’ perspective, only authenticated, rate-limited requests arrive.
Request aggregation takes this further. A single client request triggers calls to multiple upstream services. The gateway collects the responses and returns one combined result. Mobile apps benefit most here: one round trip instead of six, on a network where latency adds up.
Protocol Translation#
Not all services speak the same protocol. Internal services might use gRPC for efficiency. Mobile clients speak HTTP/1.1. The gateway translates. Internally, services communicate with fast binary protocols. Externally, the gateway exposes a clean REST or GraphQL API. Clients don’t care what the internals look like.
At Oracle#
Our telecom platform had 15 internal services accessed directly by network controller clients. When we introduced rate limiting, we had to add it to all 15. When we added a new auth scheme, same thing. We introduced a gateway using Spring Cloud Gateway and consolidated auth, rate limiting, and request logging in one place. When we later changed the auth mechanism, it was one change in one place instead of 15.
What I’m Learning#
A gateway can become a bottleneck. Everything goes through one process. If it goes down, everything goes down. Running multiple gateway instances behind a load balancer and keeping the gateway stateless are not optional.
How do you handle gateway failures in your architecture, and what’s your fallback?