Comparisons
Ten pairs that get conflated in real conversations. Neither column wins — what decides is the requirement. Each record leads with the confusion, because the confusion is the reason the record exists.
Monolith vs Microservices
Microservices get chosen as the answer to "the codebase is big". Size is a modularity problem; distribution is an organisational and operational one. Splitting converts in-process calls into network calls, so partial failure, versioning, distributed tracing and data consistency all become your problem — and a badly-bounded monolith becomes a badly-bounded distributed system.
Almost always at the start, and for a long time after: one transaction, one deploy, one trace, refactorable boundaries.
When independent deployment, independent scaling or team autonomy is the actual constraint — and you can pay the operational cost.
| Dimension | One deployable (ideally modular) | Independently deployed services |
|---|---|---|
| Transactions | One database transaction spans the change | Sagas, outboxes, eventual consistency |
| Refactoring a boundary | A rename | A migration across two deploy cycles |
| Failure modes | The process is up or down | Partial failure, cascading failure, retry storms |
| Scaling | Scale the whole thing | Scale the hot service only |
| Debugging | One stack trace | Distributed tracing, or nothing |
| Prerequisite | Discipline about module boundaries | CI/CD, observability and on-call maturity |