0% completed
Capstone: Would You Use Microservices Here?
On This Page
- How to Use This Capstone
- Scenario A: The Startup
- Scenario B: The Release Train
- Scenario C: The Hot Component
- The Pattern Across All Three
- TL;DR
1. How to Use This Capstone
This capstone gives you three scenarios. Each one is a realistic version of the same interview question: "would you use microservices for this?"
For each scenario, do three things. Read the setup. Say your answer out loud before you read further. Then compare your answer against the model answer and the scoring notes.
The out-loud step is the whole point. Recognition and recall are different skills. Reading a good answer and agreeing with it feels like learning, but the interview tests whether you can produce the answer with nothing in front of you.
A strong answer to any decision question has the same four parts:
- Restate the constraint that decides it. Team size, domain stability, load shape (how traffic and resource needs spread across the system), or ops maturity (how ready the team is to run many services in production).
- Give the decision. Commit to one. Hedging between options without choosing scores worse than either choice.
- Name what you are giving up. Every architecture pays something; say what.
- Name the trigger that would change your mind. This turns a static opinion into engineering judgment.
2. Scenario A: The Startup
"We are a 10-day-old startup, 8 engineers, building a B2B invoicing product. Our CTO wants to start with microservices so we don't have to rewrite later. You are the founding architect: what do you recommend?"
One term before you answer. B2B means business to business. The customers are other companies, not consumers.
Say your answer, then read on.
Model answer: "I would recommend a modular monolith, and I would push back on the rewrite argument directly. With 8 engineers we have one team, so the coordination problem microservices solve does not exist here yet. What we would pay for them is real, though: every feature would cross network boundaries, we would need distributed tracing and per-service pipelines before we have a single customer, and our domain boundaries are guesses right now because the product will change shape as we learn. Wrong boundaries are the expensive part, and they are far cheaper to fix inside one codebase. So we ship one deployable and one database, but we enforce module boundaries from day one: separate modules for invoicing, customers, and payments, each owning its own tables, with no cross-module table access. That discipline is what makes a later extraction cheap, which honestly addresses the CTO's concern better than starting distributed does. The trigger to revisit: when we have several teams genuinely blocking each other's releases, or a component like PDF rendering whose load diverges enough to need its own scaling."
Two terms from that answer are worth defining. Distributed tracing means following a single request as it hops between services, so you can see where it slowed down or failed. Per-service pipelines means every service needs its own build, test, and deploy automation.
Scoring notes: Full marks requires three things.
- The modular monolith, not just "monolith." A modular monolith is one deployable app with strict module boundaries inside it. Think of each module like a library with a public interface: other modules call the interface and never reach into its tables.
- An explicit reason the CTO's "avoid the rewrite" logic fails: boundaries are guesses right now, and clean modules make a later extraction cheap.
- A concrete revisit trigger.
Bonus signal: noting that a specific carve-out (like PDF rendering) can be extracted alone someday without adopting microservices everywhere.
3. Scenario B: The Release Train
"You join an e-commerce company: 300 engineers, around 40 teams, one Java monolith. Releases go out twice a month on a train; a bug in any team's code rolls back everyone. Teams openly plan around missing the train. Would you move to microservices?"
Say your answer, then read on.
Model answer: "Yes, this is the situation microservices exist for: the constraint that decides it is 40 teams measurably blocked by one deployment unit. The coordination cost is visible and growing, and it is organizational, so the fix has to change the organization's units of deployment. But I would not do a big-bang decomposition. I would start with the strangler approach: pick one or two boundaries where the case is strongest, meaning a domain a single team owns, with its own data and a load or release profile that diverges from the rest. Checkout and search are typical first candidates. Each extraction gets its own database from day one, because sharing tables with the monolith would keep the coupling and add a network in the middle. What we are giving up: cross-boundary transactions and easy debugging, so the platform work (tracing, centralized logging, deployment automation) has to land alongside the first services, not after them. Success metric: deployment frequency per team and rollback blast radius, measured before and after. And the end state does not have to be 300 services; it has to be release independence. If we get there with 15 services around a smaller core monolith, that is success."
Scoring notes: Full marks requires four things. A yes, with the reason tied to team count and release contention, not scale or traffic. An incremental migration rather than a big-bang rewrite (splitting everything at once in one giant project). Data ownership from the first extraction. And the point that the end state is measured in release independence rather than service count.
Two terms from that answer are worth being able to define. The strangler approach means extracting services one at a time while the monolith keeps running and shrinks over time. The name comes from the strangler fig, a plant that grows around a tree and slowly replaces it. Blast radius means how much of the system one failure or one rollback takes down with it.
4. Scenario C: The Hot Component
"A 25-engineer company runs a profitable photo-book product as a Rails monolith. Everything is fine except image processing: it consumes 80% of compute, needs GPU instances the rest of the app wastes money on, and a traffic spike in uploads slows down checkout. Microservices?"
Say your answer, then read on.
Model answer: "Not microservices, one microservice. The constraint that decides it is load shape: one component whose resource profile (GPU, spiky, compute-heavy) diverges completely from the rest of a system that is otherwise healthy. Extracting image processing into its own service, fronted by a queue, solves all three named problems at once: it scales independently on GPU instances, the rest of the app goes back to cheap CPU instances, and the queue means an upload spike lengthens processing latency instead of touching checkout at all. Image processing is also a naturally clean boundary: the interface is 'here is an image and a job spec, tell me when you are done,' jobs are self-contained, and it needs no cross-service transactions. What we pay: an async workflow, so the product now needs job status handling and retry logic for failed processing, and the team takes on operating a queue. That cost is small and local. The rest of the monolith stays exactly as it is, and the trigger for any further extraction would be the same kind of evidence: a specific component with a divergent profile, not a general desire to modernize."
Scoring notes: Full marks requires refusing the false binary. A false binary is a question framed as two options when a third exists. Here the third option is one targeted extraction, not an architecture migration.
Full marks also requires the queue as the decoupling mechanism, and the observation that this particular boundary is clean (self-contained jobs, no distributed transactions). Strong candidates also name the new costs (async status handling, retries) without being asked.
5. The Pattern Across All Three
Notice what did the deciding in each scenario. Team structure decided A and B. Load shape decided C. Never traffic volume by itself, never company prestige, never "modern versus legacy."
The scenario changes. The deciding variables barely do. Interviewers change the surface story on purpose, and that is what makes this question preparable without being memorizable.
💡 If you can only rehearse one sentence from this module, rehearse a version of: "My default is a modular monolith; I split when the evidence shows teams blocking each other or a component whose needs diverge, and each split has to pay for its own operational cost."
Next comes the question that follows every "yes, split" decision: where exactly do you draw the lines? That is the next module's subject, and it is where most real-world microservice systems go wrong first.
6. TL;DR
| Answer shape | Deciding constraint, committed decision, named costs, revisit trigger. |
| Scenario A | 8-engineer startup: modular monolith; boundaries are guesses; modules make later extraction cheap. |
| Scenario B | 300 engineers on a release train: yes; strangler extraction; success = release independence, not service count. |
| Scenario C | One divergent component: one microservice behind a queue, not an architecture migration. |
| Deciding variables | Team structure and load shape. Not traffic, not fashion. |
Flashcards Review
What four parts does a strong answer to a "would you use microservices?" question have?
On This Page
- How to Use This Capstone
- Scenario A: The Startup
- Scenario B: The Release Train
- Scenario C: The Hot Component
- The Pattern Across All Three
- TL;DR