What are the trade-offs between a monolith and microservices architecture?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
A monolith is a single deployable unit — simple to develop, test, and deploy at small scale, but it couples teams, scales as a whole, and accumulates complexity. Microservices split the system into independently deployable services — teams move fast and scale parts independently, but you pay for network complexity, distributed data, observability, and operational overhead. Start monolith; extract services when team size or scaling needs force you to.
Detailed explanation
Monolith: one codebase, one deployment, in-process calls between modules. Pros: trivial debugging (single process), no network latency between modules, simple transactions (single DB), easy to deploy and test end-to-end. Cons: scaling requires replicating the whole app even if only one feature is hot; a bug in one module can bring down everything; the codebase becomes hard to reason about as it grows; and multiple teams stepping on each other create coordination overhead. Microservices: each service owns its data and logic, communicates over the network (HTTP/gRPC or messaging), and deploys independently. Pros: teams own services end-to-end (Conway's Law alignment); scale only the hot services; choose the right tech per service; isolate failures. Cons: distributed systems are hard — network calls fail, latency adds up, data is split across services (no cross-service JOINs, eventual consistency), debugging requires distributed tracing, and you need CI/CD, service discovery, and observability per service. The pragmatic path: begin with a well-structured monolith (modular boundaries, clear interfaces), then extract services when (a) a module needs independent scaling, (b) a team needs autonomy, or (c) a module needs a different tech stack. Premature microservices is a common anti-pattern — do not distribute what you do not yet understand.
Example
Monolith (early-stage startup):
- One Next.js + Express app, one PostgreSQL DB.
- Three engineers deploy together. Fast iteration.
Microservices (growth stage, 40 engineers):
- User service, Order service, Inventory service, Notification service.
- Each owns its database; communicate via gRPC + events.
- Order service scales 10x during sales; others stay small.Interview tip
Give the trade-offs honestly (do not pretend microservices are always better). Then state the pragmatic rule: start monolith, extract when scaling or team autonomy demands it. Naming Conway's Law signals architectural maturity.
Common mistakes
- Saying microservices are always the right choice.
- Not mentioning the distributed-systems costs (network, data, debugging).
- Forgetting that each service should own its own database.