The System Design Interview: A Step-by-Step Framework
A step-by-step framework for system design interviews: clarifying requirements, estimates, APIs, data models, high-level design, deep dives and trade-offs.
Microservices vs Monolith: A Decision Framework
Microservices or a monolith? The real costs and benefits of each, the modular monolith middle ground, and a practical framework for deciding and migrating.
Key takeaways
- A well-structured monolith is the right default for most new products and small teams.
- Microservices pay off when independent teams, scaling or deployment needs outweigh distributed-system complexity.
- A modular monolith keeps options open: split services out only when there’s a clear reason.
On this page
Few architecture debates generate more heat than microservices vs monoliths. The right choice depends less on technology than on your team, your product’s maturity and the problems you actually have.
Definitions
- Monolith: one deployable application containing all functionality, usually with one database.
- Microservices: many small services, each owning a business capability and its data, deployed independently and communicating over the network.
- Modular monolith: one deployable application with strong internal boundaries between modules.
The trade-offs
| Monolith | Microservices | |
|---|---|---|
| Simplicity | One codebase, one deploy, easy debugging | Many services, networks, distributed tracing |
| Development speed early on | Fast | Slower: more setup and coordination |
| Independent deployment | No: everything ships together | Yes, per service |
| Scaling | Scale the whole app | Scale hot services independently |
| Team autonomy | Harder as teams grow | Teams own services end to end |
| Failure isolation | One bug can take everything down | Failures can be contained, with care |
| Data consistency | Simple transactions | Distributed data; eventual consistency |
Hidden costs of microservices
- Network latency and partial failures between services; see the CAP theorem
- Distributed transactions and data duplication (see the saga pattern)
- Observability: logs, metrics and tracing across services
- Infrastructure: service discovery, load balancing, deployment pipelines
- Versioning APIs between teams (compare REST, gRPC and GraphQL)
A decision framework
Microservices are worth considering when several of these are true:
- Multiple teams are blocked by each other in one codebase.
- Parts of the system have very different scaling needs.
- Parts need different release cadences or technologies.
- You have the platform maturity: CI/CD, monitoring and on-call practices.
- Domain boundaries are well understood.
If most aren’t true, a modular monolith is usually the better choice.
Migrating gradually
Use the strangler fig approach: route one capability at a time to a new service while the monolith keeps running, and communicate asynchronously where possible (see Kafka vs RabbitMQ vs SQS). Start with a boundary that has clear ownership and few dependencies.
In interviews
Don’t default to microservices. Start with a simple design, then explain which components you’d split out as scale and team size grow, and why. That fits our system design interview framework.
Frequently asked questions
Are microservices more scalable?
They allow independent scaling of components, but a well-designed monolith can scale a long way horizontally.
When should a startup use microservices?
Rarely at the start. Most benefit from a modular monolith until team size or scaling needs demand more.
What is a modular monolith?
A single application with enforced boundaries between modules, making a later split far easier.
Sources
Every article is edited by a human and checked against our editorial policy. Spotted a mistake? Tell us.
Keep reading
Design a URL Shortener: A System Design Walkthrough
A URL shortener system design: requirements, capacity estimates, API, short-code generation, database choice, caching, analytics and scaling trade-offs.
Designing a Notification System at Scale
How to design a notification system for push, email and SMS at scale: requirements, architecture, queues, templates, preferences, retries and deduplication.