Question presented to candidate: "We are a growing company with one big application. Some engineers want to split it into microservices. What are the real trade-offs, and how would you decide?"
What a strong answer should cover:
- Clear definitions: a monolith is one deployable unit (ideally a modular monolith with enforced boundaries); microservices are independently deployable services, each owning its data, talking over the network
- What the network costs: latency per hop, tail latency amplification with fan-out, availability that multiplies across synchronous dependencies, partial failure, versioned APIs
- Data: one ACID transaction in a monolith versus sagas with compensations and visible intermediate states across services; no cross-service joins
- What microservices buy: independent deploys and scaling, fault and team isolation, technology choice per service; the price in operations (observability, CI/CD per service, service discovery, on-call)
- A decision rule driven by team size and real pain points, migration with the strangler fig pattern, and real case studies in both directions (Segment, Prime Video)
Clarifying questions expected:
- How many engineers and teams, and where is the pain today: deploy conflicts, scaling, reliability, or slow builds?
- Do parts of the system have very different load, latency or compliance needs?
Code / implementation expected: Optional โ the example quantifies hop latency, fan-out tails, availability chains, rollback versus saga, scaling memory and team communication paths.