// 2026-03-19 · 6 min read
Modular monolith vs. microservices: our decision checklist
The questions we ask before adding distributed-systems complexity.
// The short version
A decision framework you can use
Good engineering writing should help a team make its next decision. The ideas below are intentionally practical: start from constraints, make trade-offs explicit and leave a system that can be observed.
// In practice
The details that matter
01
Boundaries before deployment units
A modular monolith is often the fastest way to discover real boundaries. Keep modules explicit, APIs typed and dependencies directional before splitting processes across a network.
02
Distributed complexity needs a reason
Choose microservices when independent scaling, isolation, team ownership or deployment needs justify the operational cost. Service count alone is not an architecture strategy.
03
A practical decision checklist
Ask who owns the data, what must scale independently, which failures are acceptable and how the system will be observed. If the answers are unclear, keep the boundary in-process and make it stronger.
Keep building