Early-stage startup (monolith wins)
Who uses it: Founder/CTO choosing the first architecture
One small team, one product, fast iteration
Monolith: cross-module changes in one PR
One database, simple transactions
Single deploy, single staging environment
Microservices overhead would slow this team down
Why this works: Early-stage almost always picks the monolith — the diagram's left side is what you ship, because a single team iterating fast benefits more from in-process function calls than from network boundaries between services.
Scaling pain (monolith breaks down)
Who uses it: Team where the monolith has become the bottleneck
Multiple teams stepping on each other in one repo
Deploy queue: any change waits behind everyone else's
One slow query takes down everything
Independent scaling impossible — entire app scales together
Tech-stack lock-in: one language, one framework
Why this works: Scaling pain is when you start to feel the cost of staying monolithic — the diagram's left side becomes a liability, because coordination, deploys, and incidents all share one bottleneck.
Gradual extraction (strangler fig)
Who uses it: Team migrating to microservices without a rewrite
Keep the monolith running
Extract one bounded context at a time into a service
API gateway routes new traffic to extracted services
Database split happens with each extraction
Decommission monolith routes as they're replaced
Why this works: The strangler fig pattern avoids a big-bang rewrite — the diagram evolves over months, with the monolith on the left shrinking and the microservices column on the right growing one service at a time.
Modular monolith (the middle ground)
Who uses it: Team that wants module boundaries without operational cost
One deploy, but strict module boundaries in code
Internal API contracts between modules
Optional: separate schemas per module in one database
Easier to extract later when actually needed
No network calls, no per-service ops overhead
Why this works: A modular monolith keeps the operational simplicity of the left side while imposing the discipline of the right — modules talk through stable interfaces but ship together, postponing the cost of microservices until you actually need them.
