Microservices vs Monolith
Overview
Monolithic architecture packages an application's entire feature set into a single deployable unit, while microservices architecture splits that feature set into small, independently deployable services that communicate over the network. The choice between them shapes how a team builds, deploys, scales, and operates a system.
Key Concepts
A monolithic architecture keeps all modules - UI, business logic, and data access - in one codebase that compiles and deploys as a single artifact. Modules call each other through fast in-process function calls, and they typically share one database.
A microservices architecture decomposes the system along business capabilities into independent services. Each service owns its data, exposes an API, deploys on its own schedule, and can scale and fail independently. Clients usually reach the services through an API gateway, and services often coordinate asynchronously using event-driven architecture rather than synchronous calls.
The core distinction is the unit of change and the unit of scale. In a monolith both are the whole application; in microservices both are a single service.
Trade-offs
| Dimension | Monolithic | Microservices |
|---|---|---|
| Deployment | One unit; redeploy the whole app | Independent per service |
| Scaling | Scale the entire app | Scale hot services in isolation |
| Data | Usually one shared database | Database per service |
| Fault isolation | A crash can affect everything | Failures contained to a service |
| Velocity, small team | Fast; little overhead | Coordination overhead slows delivery |
| Velocity, many teams | Merge and deploy contention | Teams ship independently |
| Operational cost | Low | High: networking, orchestration, monitoring |
| Consistency | Simple local ACID transactions | Needs distributed transactions |
Choose a monolith for early-stage products, small teams, unclear domain boundaries, and low operational maturity; the simplicity accelerates iteration. Choose microservices when many teams must ship in parallel, when parts of the system have very different scaling profiles, and when bounded contexts are well understood. A modular monolith - clean internal boundaries inside one deployable - is often the pragmatic middle ground that preserves an easy path to later extraction.
Interview Tips
- Default to a monolith or modular monolith unless the requirements clearly justify splitting, and state that reasoning out loud.
- Invoke Conway's Law: architecture tends to mirror team structure, so microservices pay off mainly when you have many teams.
- Name the hidden costs of microservices - network latency, partial failure, distributed data, and heavier observability - so the interviewer sees you understand the operational bill, not just the buzzword.
Summary
- Monolithic architecture deploys the whole application as one unit; microservices deploy independent services per business capability.
- Monoliths optimize simplicity and speed for small teams; microservices optimize independent scaling and parallel delivery for large organizations.
- Microservices trade code-level simplicity for operational complexity: networking, orchestration, and distributed data.
- A modular monolith is a strong default that keeps a clean migration path open.
- Let team size, scaling needs, and domain clarity - not fashion - drive the decision.