Each step up buys independence and costs ops effort
A style is a set of constraints; qualities emerge when you respect them. A distributed monolith pays microservices’ cost for a monolith’s independence.
Why this style?
Bad: “Netflix uses it”
Hype isn’t a force acting on your system; it sounds like fashion.
Good: Name the force first
“One team, a new domain: modular monolith. Payments apart, for its audit scope.”
Four answers before you pick any style
- How many teams will build it?
- How well do we understand the domain?
- What does the load look like?
- Which latency, consistency and compliance limits are hard?
2,400/s
requests a second on average, one Q&A app
Stack Overflow, 2016: 209 million a day on nine web servers. Traffic alone doesn’t force a split; team count, workload shape or isolation usually do.
Not “which style?” but “which style where?”
A modular monolith core. Services only where a force demanded: payments for compliance, rider location for load shape. Events, a queue-fed worker, functions, and cells per region.
Your style will change. Where should you be careful?
One-way doors
With the data. Extracting a module behind its interface is routine. Splitting a shared database or publishing an event schema many teams use is not.
3 engineers to 300: what forced each style change?
An illustrative startup: a release queue and a PCI audit, then 40 teams and city launches. Traffic alone never did.
The interview line
Name the force before the style. Start with a modular monolith; add a style only where a force demands it.