our mobile app talks to 3 backend services directly.
A 4th one ships next sprint. The mobile team is already drowning.
Every new service means a new domain to whitelist, a new auth scheme to wire, and a new error shape to parse. You’re asked to reduce coupling before NotificationService lands.
Here’s the setup:
Mobile → UserService (<a href="http://users.api.com" target="_blank" rel="noopener nofollow">users.api.com</a>)
Mobile → OrderService (<a href="http://orders.api.com" target="_blank" rel="noopener nofollow">orders.api.com</a>)
Mobile → PaymentService (<a href="http://payments.api.com" target="_blank" rel="noopener nofollow">payments.api.com</a>)
…and NotificationService next sprint.
The client is doing routing the backend should be doing. What do you do?
A) Add an API Gateway — single entry point, all services hide behind one domain.
B) Build a BFF (Backend for Frontend) — a dedicated aggregation layer tailored for mobile.
C) Put a Load Balancer in front of all services — single IP, distributed traffic.
D) Switch to GraphQL Federation — one unified schema the client queries.
Three of these are real patterns you’d use in production. Only one of them actually solves the problem in front of you.
Pick one — A, B, C, or D — and tell me why. I’ll drop the full breakdown in the comments (including why two of the wrong answers are close enough to trick senior engineers).
If this is the kind of tradeoff question your team argues about, share it with them. The debate is worth more than the post.
Drop your answer 👇

Joud Awad

A system design challenge asking readers to choose the best pattern for reducing mobile client coupling when multiple backend services are involved. The scenario presents a mobile app talking directly to 3 backend services (UserService, OrderService, PaymentService) with a 4th on the way. Four options are presented: API Gateway, BFF (Backend for Frontend), Load Balancer, and GraphQL Federation. The post teases that only one truly solves the problem and promises a full breakdown in the comments.

1/30 Days System Design Question

<img src="https://media.daily.dev/image/upload/s--KacWgnGC--/f_auto/v1778099482/ugc/content_d3f5b755-7f38-49a9-9016-2ad50f6a3653?_a=BAMAMiWQ0" alt="ChatGPT Image May 6, 2026, 11_21_23 PM (2).png">
Why A wins (API Gateway):
One domain. One auth flow. One error contract. The client stops caring that UserService, OrderService, and PaymentService live on different hosts — the gateway hides them behind <a href="http://api.yourapp.com/users" target="_blank" rel="noopener nofollow">api.yourapp.com/users</a>, /orders, /payments. When NotificationService ships next sprint, you add one route. The mobile app ships zero changes. That’s what “future-proof” actually means at the transport layer: new services cost nothing on the client side.
It also centralizes the things you don’t want scattered across 4 codebases: authN/authZ, rate limiting, request logging, TLS termination, versioning. Netflix, Stripe, and every mature fintech run some form of this.

Why D is wrong here (GraphQL Federation):
GraphQL Federation solves schema unification, not transport-layer coupling. You’d still need a gateway in front of the federation, and you’d rewrite every backend service to expose a GraphQL subgraph. That’s a multi-quarter migration to solve a problem you can fix in a sprint with a gateway.

Also, it would mean a lot to me if you could support my content and stay in touch 🙏
<ul>
<li>YouTube: <a href="https://www.youtube.com/@system-design-lab" target="_blank" rel="noopener nofollow">https://www.youtube.com/@system-design-lab</a></li>
<li>LinkedIn: <a href="https://www.linkedin.com/in/joud-awad/" target="_blank" rel="noopener nofollow">https://www.linkedin.com/in/joud-awad/</a></li>
<li>Medium Blog: <a href="https://joudwawad.medium.com/" target="_blank" rel="noopener nofollow">https://joudwawad.medium.com/</a></li>
<li>Substack: <a href="https://joudawad.substack.com/" target="_blank" rel="noopener nofollow">https://joudawad.substack.com/</a></li>
</ul>

Why B is the trap answer (BFF):
BFF is a legitimate pattern — and it’s close enough to fool a lot of senior engineers. But BFF solves a different problem: data shape per client type. Mobile needs a slim payload, web needs a richer one. BFF gives each client its own backend that aggregates and reshapes data.
In this scenario, the pain isn’t payload shape — it’s domain sprawl and coupling. Putting a BFF here trades 4 URLs for 1 URL + 1 extra service you own end-to-end. That’s the wrong tradeoff.