Back to roadmap
Module 5 · APIs & Application LayerDay 04725 min

Microservices vs Monolith

One deployable vs many — both are valid; pick consciously.

← PreviousNext →
Day 047

Microservices vs Monolith

Monolith
service
Users-svc
service
Orders-svc
service
Pricing-svc
service
Signal path
Bounded contexts split into services
Monolith
service
async
Users-svc
service
Monolith
service
async
Orders-svc
service
Monolith
service
async
Pricing-svc
service
Memory hook

Microservices vs Monolith: one deployable vs many

Mental model

turn boundaries into contracts

Design lens

Each split adds network and operational cost.

Recall anchors
MonolithMicroservicesAnti-pattern

Why it matters

Monoliths are single deployables — fast to build, simple to operate, but a coupling magnet at large team sizes. Microservices split by domain to allow independent deploy and scale, at the cost of distributed-systems complexity.

Deep dive

Don't go micro for fewer than ~30 engineers; the overhead doesn't pay off.

Drivers that do justify: independent scaling, language diversity, deploy independence, blast-radius isolation.

Distributed monolith: services that must deploy together because of tight coupling — worst of both worlds.

Demo / scenario

Splitting a monolith.

  1. Identify domain boundaries (DDD bounded contexts).
  2. Extract a service with its own DB.
  3. Move the call site behind an interface.
  4. Cut over with feature flag; verify SLOs.

Tradeoffs

  • Each split adds network and operational cost.
  • Cross-service transactions need sagas.
  • Observability becomes harder; instrument first.

Diagram

Monolith
Users-svc
Orders-svc
Pricing-svc
Bounded contexts split into services.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →