--- title: 60/60 Days System Design Questions | daily.dev description: A system design challenge posing the classic architecture decision for a new SaaS platform needing 50,000 RPS, multi-tenancy, real-time data, global users, and... canonical: https://daily.dev/posts/60-60-days-system-design-questions-flzgx5ght twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: 60/60 Days System Design Questions | daily.dev og:description: A system design challenge posing the classic architecture decision for a new SaaS platform needing 50,000 RPS, multi-tenancy, real-time data, global users, and... og:url: https://daily.dev/posts/60-60-days-system-design-questions-flzgx5ght og:image: https://api.daily.dev/og/posts/FLzgx5ghT.png og:image:alt: 60/60 Days System Design Questions 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. # 60/60 Days System Design Questions **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 203 upvotes · 45 comments ## Summary A system design challenge posing the classic architecture decision for a new SaaS platform needing 50,000 RPS, multi-tenancy, real-time data, global users, and AI inference. Four architectural approaches are presented: distributed microservices from day one, a modular monolith with incremental extraction, serverless with Lambda/DynamoDB/SQS, and event-driven architecture with Kafka as the backbone. This is framed as the final entry in a 60-day system design series, inviting engineers to debate the tradeoffs. ## Content You're designing the architecture for a new SaaS platform from scratch. It needs to handle 50,000 requests per second at launch. Multi-tenant. Real-time data. Global users. AI inference built in. Your CTO gives you 3 months and a blank slate. You've been thinking about this for a week. You finally sit down to draw the first box. Here's what engineers actually debate in that room: **A)** Start with a distributed microservices architecture — services for auth, billing, inference, and core domain from day one. Scale each independently. **B)** Start with a modular monolith — one deployable unit with clean internal module boundaries. Extract services only when a specific boundary proves it needs it. **C)** Start with serverless — Lambda/Cloud Functions for every endpoint, DynamoDB for state, SQS for async. Zero infra to manage, scales to zero between bursts. **D)** Start with an event-driven architecture — Kafka as the backbone, all services communicate through events, no direct API calls between services from day one. 60 days. 60 tradeoffs. This is the last one. Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments. If this series has been useful, share it forward. One engineer reading this might avoid a decision that costs their team 6 months of refactoring. Drop your answer 👇 A full eBook with all the series questions and answers will be available soon for people who want to read all of them at once! Stay tuned for the next series, which is going to be published very soon in the upcoming days! #60DaysOfSystemDesign #SystemDesign #SoftwareArchitecture #BackendEngineering ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 22 upvotes > **B) Modular Monolith — right** > > > The constraint isn't scale. It's the 3-month runway plus uncertainty about domain boundaries. > > > A modular monolith gives you: > > > • Fast iteration — no network serialization overhead, no cross-service API contracts to version > > • Real module boundaries enforced in code (auth, billing, inference, core domain — no shared DB tables, no cross-module direct calls) > > • Single deploy, single observability surface, single transaction boundary > > • The option to extract services later — when you know exactly which boundary is real > > > When billing hits 10k RPS independently... **@joudawad** · 9 upvotes > **D) Event-driven from day one — wrong** > > > This one trips up engineers who've read about Kafka at Netflix and Uber. > > > Event-driven is the right answer — _for_ Netflix and Uber, after they've already mapped their domain. > > > Starting with Kafka before you have a working system means: > > > • Every feature needs an event schema, a producer, and a consumer before it works > > • Debugging "why didn't this event get processed" during week 2 of development > > • Eventual consistency as the default when you don't yet know which operations need strong consistency > > • Kafka operational overhead before you've... **@joudawad** · 8 upvotes > **C) Serverless — wrong (senior engineer trap)** > > > "Scales to zero" sounds great until you price out 50k RPS sustained on Lambda. > > > The math: > > > • 50,000 req/s × 100ms avg = 5,000 concurrent Lambda executions > > • At that scale you're paying more than a reserved EC2 cluster > > • Cold starts are real and you promised "real-time data" > > • AI inference in Lambda = cold start + memory limit + 15-min hard timeout = pain > > > Serverless wins for bursty, unpredictable event workloads. SaaS with consistent load and real-time requirements is not that workload. **@joudawad** · 8 upvotes > **A) Microservices from day one — wrong** > > > 50,000 RPS sounds like you need microservices. It doesn't. > > > That's a solved load balancing problem, not a distribution problem. > > > What microservices from day one actually gives you: > > > • 6+ independently deployable services before you've found your real domain boundaries > > • Distributed transactions across auth, billing, inference, and core domain > > • Network hops on every request that used to be in-process calls > > • 3 months of infra work instead of product > > > Amazon's "two-pizza teams" rule was for _existing_ services with known boundaries. Not for... **@joudawad** · 6 upvotes > Also, it would mean a lot to me if you could support my content and stay in touch 🙏 > > - YouTube: [https://www.youtube.com/@system-design-lab](https://www.youtube.com/@system-design-lab) > - LinkedIn: [https://www.linkedin.com/in/joud-awad/](https://www.linkedin.com/in/joud-awad/) > - Medium Blog: [https://joudwawad.medium.com/](https://joudwawad.medium.com/) > - Substack: [https://joudawad.substack.com/](https://joudawad.substack.com/) --- [View this post on daily.dev](https://daily.dev/posts/60-60-days-system-design-questions-flzgx5ght) ```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/60-60-days-system-design-questions-flzgx5ght","headline":"60/60 Days System Design Questions","text":"A system design challenge posing the classic architecture decision for a new SaaS platform needing 50,000 RPS, multi-tenancy, real-time data, global users, and AI inference. Four architectural approaches are presented: distributed microservices from day one, a modular monolith with incremental extraction, serverless with Lambda/DynamoDB/SQS, and event-driven architecture with Kafka as the backbone. This is framed as the final entry in a 60-day system design series, inviting engineers to debate the tradeoffs.","url":"https://daily.dev/posts/60-60-days-system-design-questions-flzgx5ght","datePublished":"2026-07-05T15:25:15.206Z","dateModified":"2026-07-06T04:21:23.365Z","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":81870}},"image":"https://media.daily.dev/image/upload/s--cECt-54q--/f_auto/v1783265121/posts/FLzgx5ghT?_a=BAMAMicg0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":203},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":45}],"comment":[{"@type":"Comment","text":"B) Modular Monolith — right\nThe constraint isn’t scale. It’s the 3-month runway plus uncertainty about domain boundaries.\nA modular monolith gives you:\n• Fast iteration — no network serialization overhead, no cross-service API contracts to version\n• Real module boundaries enforced in code (auth, billing, inference, core domain — no shared DB tables, no cross-module direct calls)\n• Single deploy, single observability surface, single transaction boundary\n• The option to extract services later — when you know exactly which boundary is real\nWhen billing hits 10k RPS independently and needs separate scaling, you extract it. The boundary is already clean. The migration is a refactor, not a rewrite.\nThe AI inference piece specifically: inference latency is dominated by model I/O (50–500ms), not your application code. That’s a reason to put it behind a clean internal interface — not a reason to make it a separate service on day one.","datePublished":"2026-07-05T15:26:34.566Z","url":"https://daily.dev/posts/FLzgx5ghT#c-1M0oH5PKw","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":22}},{"@type":"Comment","text":"D) Event-driven from day one — wrong\nThis one trips up engineers who’ve read about Kafka at Netflix and Uber.\nEvent-driven is the right answer — for Netflix and Uber, after they’ve already mapped their domain.\nStarting with Kafka before you have a working system means:\n• Every feature needs an event schema, a producer, and a consumer before it works\n• Debugging “why didn’t this event get processed” during week 2 of development\n• Eventual consistency as the default when you don’t yet know which operations need strong consistency\n• Kafka operational overhead before you’ve validated the product\nEvent-driven is an optimization for a known system. Not a foundation for an unknown one.","datePublished":"2026-07-05T15:25:35.804Z","url":"https://daily.dev/posts/FLzgx5ghT#c-jxH7N2jQV","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":9}},{"@type":"Comment","text":"C) Serverless — wrong (senior engineer trap)\n“Scales to zero” sounds great until you price out 50k RPS sustained on Lambda.\nThe math:\n• 50,000 req/s × 100ms avg = 5,000 concurrent Lambda executions\n• At that scale you’re paying more than a reserved EC2 cluster\n• Cold starts are real and you promised “real-time data”\n• AI inference in Lambda = cold start + memory limit + 15-min hard timeout = pain\nServerless wins for bursty, unpredictable event workloads. SaaS with consistent load and real-time requirements is not that workload.","datePublished":"2026-07-05T15:25:31.116Z","url":"https://daily.dev/posts/FLzgx5ghT#c-V001RlOTJ","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":8}},{"@type":"Comment","text":"A) Microservices from day one — wrong\n50,000 RPS sounds like you need microservices. It doesn’t.\nThat’s a solved load balancing problem, not a distribution problem.\nWhat microservices from day one actually gives you:\n• 6+ independently deployable services before you’ve found your real domain boundaries\n• Distributed transactions across auth, billing, inference, and core domain\n• Network hops on every request that used to be in-process calls\n• 3 months of infra work instead of product\nAmazon’s “two-pizza teams” rule was for existing services with known boundaries. Not for new domains where you’re still discovering what the boundaries are.\nThe boundary is the hard part. You don’t know it yet.","datePublished":"2026-07-05T15:25:27.245Z","url":"https://daily.dev/posts/FLzgx5ghT#c-mvpFdJjnJ","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":8}},{"@type":"Comment","text":"Also, it would mean a lot to me if you could support my content and stay in touch 🙏\n\nYouTube: https://www.youtube.com/@system-design-lab\nLinkedIn: https://www.linkedin.com/in/joud-awad/\nMedium Blog: https://joudwawad.medium.com/\nSubstack: https://joudawad.substack.com/","datePublished":"2026-07-05T15:26:38.414Z","url":"https://daily.dev/posts/FLzgx5ghT#c-TYB1xizyA","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":6}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh","name":"Joud Awad"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Joud Awad","item":"https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh"},{"@type":"ListItem","position":3,"name":"60/60 Days System Design Questions"}]} ```