Your food delivery app needs one screen. The order detail page.
To render it, the mobile client calls 5 separate services. Order status. Restaurant details. Driver location. Applied discounts. Delivery estimate.
Five HTTP calls. Five auth headers. Five points of failure.
One slow service on a bad day? The whole screen hangs.
One service goes down? The whole screen breaks.
This is what microservices look like before you put an API Gateway in front of them.
The gateway collapses those 5 calls into 1. The client sends a single request. The gateway fans out to 3 services in parallel, aggregates the responses, and returns one payload.
200ms instead of 530ms. One call instead of five.
But here’s the part most tutorials skip:
→ The gateway becomes your single point of failure
→ One slow downstream service can fill your connection pool and take down ALL routes
→ Business logic creeps in (“just one more if/else”) until you’ve rebuilt the monolith
The fix for cascading failures? Bulkhead pattern — separate connection pools per service. ETA Service goes down, only ETA calls fail. Order, Driver, Restaurant keep running.
The rule for keeping it clean: if the routing decision requires looking at the request body or calling a database, it doesn’t belong in the gateway.
I broke this down in a full deep dive — gateway internals, BFF pattern, failure modes, build vs. buy:
🔗 <a href="https://joudwawad.medium.com/api-gateway-pattern-in-microservices-when-and-how-62a0bf0ea93b" target="_blank" rel="noopener nofollow">https://joudwawad.medium.com/api-gateway-pattern-in-microservices-when-and-how-62a0bf0ea93b</a>
What’s your team’s gateway setup — managed, open-source, or custom-built? What tradeoff surprised you most?
#SystemDesign #Microservices #SoftwareEngineering #DistributedSystems #BackendEngineering

You can share you thought with this squad 

Backend Developer 

An API Gateway collapses multiple microservice calls into a single client request, improving latency and simplifying auth. However, it introduces its own risks: it becomes a single point of failure, slow downstream services can exhaust connection pools and cascade failures across all routes, and business logic tends to creep in over time. The bulkhead pattern (separate connection pools per service) mitigates cascading failures. A key rule: if routing logic requires reading the request body or querying a database, it doesn't belong in the gateway. The post also touches on the BFF (Backend for Frontend) pattern and build vs. buy tradeoffs.

The API Gateway Pattern: Design, Tradeoffs, and the Failure Modes Nobody Warns You About