Architecture Styles
Monolith, modular monolith, microservices, event-driven and serverless — and how to choose.
An architecture style is the big-picture shape of a system: how it is split into deployable parts and how those parts talk. There is no best style, only the one that fits your team size, domain and scale.
Many successful products start as a well-structured modular monolith and extract services only where independent scaling or deployment is genuinely needed.
Diagram
Key concepts
- Layered monolith
- One deployable with presentation, business and data layers. Simple to build, test and deploy.
- Modular monolith
- One deployable, but split into modules with strict boundaries. Often the best starting point.
- Microservices
- Independently deployable services, each owning its data. Scales teams, but adds network and operational cost.
- Event-driven
- Components react to events through a broker. Loose coupling and easy fan-out; harder to trace end to end.
- Serverless
- Functions run on demand on a managed platform. Pay per use; watch cold starts and vendor lock-in.
Trade-offs
Benefits
- Monolith: fastest to start, easiest to debug
- Microservices: independent deploys and scaling per service
- Event-driven: producers and consumers evolve separately
Costs
- Monolith: one bad deploy affects everything; scaling is all-or-nothing
- Microservices: distributed transactions, network failures, more infrastructure
- Event-driven: eventual consistency and harder debugging
Use it when
- Monolith or modular monolith for a small team or new product
- Microservices when several teams need to ship independently
- Event-driven when many parts must react to the same business event
Common mistakes
- A “distributed monolith”: services that must be deployed together and share a database
- Splitting by technical layer (UI service, data service) instead of business capability
- Adopting microservices before having CI/CD, monitoring and tracing
Interview questions
Q1When would you choose a modular monolith over microservices?
With a small team, an evolving domain or no need for independent scaling. You keep clear module boundaries and can extract a service later when a real need appears.
Q2What is a distributed monolith?
A system split into services that are still tightly coupled — shared database, synchronous call chains, coordinated releases. It has the costs of microservices without the benefits.
Q3How should you draw service boundaries?
Around business capabilities or bounded contexts (Orders, Payments, Catalogue), so each service owns its data and can change without coordinating with others.
Related lessons
Messaging & Microservices
Microservices Design Patterns
Decomposition, integration, data, resilience and deployment patterns for service-based systems.
Messaging & MicroservicesMessage Brokers: RabbitMQ vs Kafka vs ActiveMQ
Queues and logs for decoupling services — and how the three popular brokers differ.
FoundationsSOLID, DRY, KISS & YAGNI
Principles that keep code easy to change as a system grows.