Lesson 11 / 32
Monolith vs Microservices
Choosing between one deployable and many, and living with the tradeoff.
What each one is
A monolith ships all features as one deployable unit sharing a codebase, process, and database. Microservices split the system into independently deployable services, each owning its own data.
Why teams split
Microservices let teams deploy independently, scale hot services alone, and use different tech per service. The cost is network calls where function calls used to be, and operational complexity — service discovery, distributed tracing, versioned contracts.
One kitchen vs a food court
A monolith is one big kitchen — efficient when small, chaotic when every chef needs the same stove. Microservices are a food court: each stall (service) has its own equipment and can be renovated without closing the others, but you now need signage and shared payment (contracts, gateways) to feel like one restaurant.
Start monolith, split with pain
Most successful systems start as a well-modularized monolith and extract services only when a specific team or scale bottleneck demands it. Splitting too early adds distributed-systems cost before you've earned the benefit.