Compare a modular monolith with microservices across scalability, deployability, testability, operational cost and data consistency. When would you pick each?

### The two shapes A **modular monolith** is a single deployable artifact whose internals are partitioned by business capability (orders, billing, catalog) rather than by technical layer, with boundaries enforced by tooling — module systems, dependency rules, or architecture tests that fail the build when a module reaches into another's internals. Calls between modules are in-process calls through explicit public interfaces. **Microservices** split those capabilities into separately deployed processes, each owning its own datastore, communicating over the network (HTTP, gRPC or messaging). ### Dimension by dimension **Scalability and elasticity.** The monolith scales as a unit: to give the report generator more CPU you replicate everything, including modules that were idle. That is wasteful but operationally trivial, and vertical scaling plus a few replicas covers a very large range of real workloads. Microservices let you run forty instances of checkout and two of admin, which matters when load profiles genuinely diverge by an order of magnitude. **Deployability.** Monolith: one pipeline, one artifact, one rollback — but every change, however small, re-deploys the whole system, so release cadence falls to the slowest common denominator and the blast radius of a bad deploy is total. Microservices: independent release trains and a small blast radius, but only if contracts are versioned and backward compatible. Services that must be deployed together in a fixed order are a *distributed monolith* — all the cost, none of the benefit. **Testability.** In-process, you can start the whole application in a test and assert real behaviour in seconds. Across a network you lose that: you rely on unit tests, consumer-driven contract tests to pin the interfaces, and a thin layer of end-to-end tests that are slow, environment-hungry and flaky. Testability usually *decreases* with distribution. **Data consistency.** A monolith can commit changes across modules in one ACID transaction. Once data is split per service, cross-service consistency needs sagas (a sequence of local transactions with compensating actions), the transactional outbox to publish events atomically with the state change, and idempotent consumers because messages arrive at least once. This is permanent complexity, not a one-off migration cost. **Fault isolation.** In a monolith a memory leak or runaway thread in one module degrades everything. Services isolate failures — but only with bulkheads, timeouts, retries with backoff and circuit breakers; without those, a slow dependency propagates and you get cascading failure, which is *worse* than the monolith case. **Cost and cognitive load.** Microservices need per-service pipelines, artifact registries, service discovery, centralised logging, distributed tracing, dashboards and an on-call rotation. That platform work is a permanent tax paid by everyone. ### Choosing Default to the modular monolith when the domain is not yet well understood, the team is small, and getting to market matters most — boundaries are cheap to move inside one process and brutally expensive to move across a network. Split when a *specific* driver demands it: a component whose scaling profile differs by an order of magnitude, a part that must release far more often, something that must fail independently, a regulated slice needing physical isolation, or an organisational need for autonomous team ownership. Extract incrementally, strangler-fig style, along the seams the modular monolith already gave you.