--- title: 1/30 Days System Design Question | daily.dev description: A system design challenge asking how to reduce coupling between a mobile app and multiple backend services before a 4th service is added. Four architectural... canonical: https://daily.dev/posts/1-30-days-system-design-question-mxghviyp7 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: 1/30 Days System Design Question | daily.dev og:description: A system design challenge asking how to reduce coupling between a mobile app and multiple backend services before a 4th service is added. Four architectural... og:url: https://daily.dev/posts/1-30-days-system-design-question-mxghviyp7 og:image: https://api.daily.dev/og/posts/MXgHViYP7.png og:image:alt: 1/30 Days System Design Question og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # 1/30 Days System Design Question **[Backend Developer ](https://daily.dev/sources/amandeep58)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 76 upvotes · 25 comments ## Summary A system design challenge asking how to reduce coupling between a mobile app and multiple backend services before a 4th service is added. Four architectural options are presented: API Gateway, Backend for Frontend (BFF), Load Balancer, and GraphQL Federation. Readers are asked to pick the best solution and explain their reasoning, with the author promising a full breakdown in the comments. ## Content 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 ([users.api.com](http://users.api.com)) Mobile → OrderService ([orders.api.com](http://orders.api.com)) Mobile → PaymentService ([payments.api.com](http://payments.api.com)) …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 👇 ## Community discussion Top comments from developers on daily.dev. **@kkelic** · 10 upvotes > I am new to system design, but I would go with **A** > > Because it gives the frontend one single entry-point to access all 4 APIs. > > It simplifies routing, auth, security, logging and hides internal services behind one domain. > > LB is mainly for traffic distribution, not so sure for other options. **@joudawad** · 7 upvotes >  > > **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 [api.yourapp.com/users](http://api.yourapp.com/users), /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... **@adrianadev13** · 3 upvotes > Hello, can you explain the wrong answers? Why they are not good? **@nidhishpareekjove** · 3 upvotes > Option A is correct, > single entry point for all requests, > for issues you mentioned, we can morph errors, etc., at single gateway service, have auth via internal k8s service call. > > B: Backend should not be built for frontend, it will limit the backend's potential in casenew services are launched like website, or we won't be able to run / test them in optimum way in smoke etc.. > > C: Load balancer is for balancing load, nginix reverse proxy might be used but it will still have the issue of different structure in different apis. For it we need to add a list of endpoints for routing, or we need to... **@joudawad** · 2 upvotes > **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. ## Similar posts on daily.dev - [Medium](https://daily.dev/posts/medium-s2gtxyizj) · Medium · 1 upvotes · 0 comments - [What is the BFF Pattern?](https://daily.dev/posts/what-is-the-bff-pattern--mn4cmqrxj) · System Design Codex · 63 upvotes · 2 comments - [GraphQL: the enterprise honeymoon is over](https://daily.dev/posts/graphql-the-enterprise-honeymoon-is-over-y1wdtocx9) · Hacker News · 2 upvotes · 0 comments - [EP208: Load Balancer vs API Gateway](https://daily.dev/posts/ep208-load-balancer-vs-api-gateway-oii0fuod4) · ByteByteGo · 22 upvotes · 1 comments --- Tags: [#career](https://daily.dev/tags/career), [#microservices](https://daily.dev/tags/microservices), [#api-gateway](https://daily.dev/tags/api-gateway) [View this post on daily.dev](https://daily.dev/posts/1-30-days-system-design-question-mxghviyp7) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/1-30-days-system-design-question-mxghviyp7","headline":"1/30 Days System Design Question","text":"A system design challenge asking how to reduce coupling between a mobile app and multiple backend services before a 4th service is added. Four architectural options are presented: API Gateway, Backend for Frontend (BFF), Load Balancer, and GraphQL Federation. Readers are asked to pick the best solution and explain their reasoning, with the author promising a full breakdown in the comments.","url":"https://daily.dev/posts/1-30-days-system-design-question-mxghviyp7","datePublished":"2026-05-06T20:53:33.703Z","dateModified":"2026-05-06T20:53:51.452Z","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0","description":"Principal Solution Architecture ","worksFor":{"@type":"Organization","name":"Metalab","logo":"https://www.google.com/s2/favicons?domain=metalab.com&sz=128"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":86280}},"image":"https://media.daily.dev/image/upload/s--VOXz45Rf--/f_auto/v1778099458/posts/6VooYN9tg?_a=BAMAMiWQ0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":76},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":25}],"comment":[{"@type":"Comment","text":"I am new to system design, but I would go with A\nBecause it gives the frontend one single entry-point to access all 4 APIs.\nIt simplifies routing, auth, security, logging and hides internal services behind one domain.\nLB is mainly for traffic distribution, not so sure for other options.","datePublished":"2026-05-08T19:31:23.067Z","url":"https://daily.dev/posts/MXgHViYP7#c-ypSdBmLwF","author":{"@type":"Person","name":"Kristijan Kelić","url":"https://daily.dev/kkelic","image":"https://media.daily.dev/image/upload/s--SQP2MK4n--/f_auto/v1760885838/avatars/avatar_SXGqLJh0L3gAhF7TbiyoC?_a=BAMAK+ZW0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":10}},{"@type":"Comment","text":"Why A wins (API Gateway):\nOne 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 api.yourapp.com/users, /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.\nIt 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.","datePublished":"2026-05-13T07:28:21.401Z","url":"https://daily.dev/posts/MXgHViYP7#c-Kfa4QsGeF","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":7}},{"@type":"Comment","text":"Hello, can you explain the wrong answers? Why they are not good?","datePublished":"2026-05-12T13:03:26.862Z","url":"https://daily.dev/posts/MXgHViYP7#c-ga5DMr1CX","author":{"@type":"Person","name":"Adriana Mucciolo","url":"https://daily.dev/adrianadev13","image":"https://lh3.googleusercontent.com/a/ACg8ocJxAMBcQDR2iukK7oydoH1XKXwwLO77qcDI-0ybc2YtWf-owm4=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"Option A is correct,\nsingle entry point for all requests,\nfor issues you mentioned, we can morph errors, etc., at single gateway service, have auth via internal k8s service call.\nB: Backend should not be built for frontend, it will limit the backend’s potential in casenew services are launched like website, or we won’t be able to run / test them in optimum way in smoke etc…\nC: Load balancer is for balancing load, nginix reverse proxy might be used but it will still have the issue of different structure in different apis. For it we need to add a list of endpoints for routing, or we need to add another identifier after domain.\nD: It might help, but as far as i have seen, most companies don’t use the graphql properly, and they just end up being structured REST APIs with TS types generated. APIs will need to be changed drastically.","datePublished":"2026-05-13T07:26:21.154Z","url":"https://daily.dev/posts/MXgHViYP7#c-WuekTw0Ok","author":{"@type":"Person","name":"Nidhish Pareek","url":"https://daily.dev/nidhishpareekjove","image":"https://lh3.googleusercontent.com/a/ACg8ocJbIVCSgqtfsYSdwzUCF5RRP-yR81pHQs3VZTWLUea8FG80k84=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"Why B is the trap answer (BFF):\nBFF 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.\nIn 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.","datePublished":"2026-05-13T07:28:27.662Z","url":"https://daily.dev/posts/MXgHViYP7#c-lG3iGQ5WM","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/squads/amandeep58","name":"Backend Developer "}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Backend Developer ","item":"https://daily.dev/squads/amandeep58"},{"@type":"ListItem","position":3,"name":"1/30 Days System Design Question"}]} ```