When should you use microservices?
“A team of eight engineers runs a monolith with 2,000 requests per second and wants to move to microservices. What would you ask them, and when is the move justified?”
What this tests
- Whether microservices are treated as a solution to a specific organisational or scaling problem
- Awareness of the distributed-systems cost: network failures, data consistency, deployment tooling, observability
- Ability to name the alternatives (modular monolith, extract one service)
- Judgment about team size and operational maturity
Answers by level
Read the beginner answer first and notice what is missing.
I would ask what problem they are trying to solve. 2,000 rps and eight engineers is well inside what a monolith handles: horizontal copies behind a load balancer scale the stateless part, and the database is the actual ceiling either way. So the justification cannot be raw throughput. Valid justifications are organisational — teams blocking each other on deploys, merge conflicts across domains — or genuinely different scaling profiles, such as one image-processing module that needs 20× the CPU of the rest and would force the whole monolith to scale with it.
The cost side is concrete: every in-process call that becomes a network call can time out, partially fail, and needs retries with idempotency; transactions across domains become sagas; a single stack trace becomes distributed tracing; one deploy pipeline becomes N, with contract versioning between them. Eight engineers running twelve services will spend a large share of their time on that platform work rather than product.
The alternative I would push first is a modular monolith: enforce boundaries in code — each module has a public API, no cross-module table access, in-process events — so that if a boundary later needs to become a network boundary, it is already drawn. Extract the one module that has a measured reason, not everything at once.
Green flags · Red flags
- Asks which organisational or scaling problem the move solves before agreeing
- Team autonomy: ties services to teams with separate domains and release cadences
- Deployment independence: names it as the primary benefit and checks whether it is needed
- Scaling needs: checks whether parts of the system have measurably different scaling profiles
- Domain boundaries: proposes a modular monolith with enforced boundaries first
- Operational cost: names the distributed-systems tax — timeouts, retries, sagas, tracing, N pipelines
- "Microservices scale better, so always use them."
- Justifies the split by throughput alone at 2,000 rps
- Proposes splitting by technical layer (an "API service", a "database service") instead of by domain
- Does not mention data ownership or cross-service transactions
- Ignores that eight people must now run the platform