Is a "modular monolith" a real middle ground, or just marketing?

It's real. A modular monolith enforces the same clean internal boundaries between components that microservices have (each module owns its own data access, communicates through defined interfaces, no reaching into another module's internals) — but all modules still deploy and run as a single process. It gets most of the maintainability benefits people associate with microservices without paying the network-latency and distributed-transaction tax, and it's a common, deliberate stepping stone before splitting out services that actually need independent scaling.

Do microservices always mean better fault isolation?

Only if failures are actually handled at the boundary. If Orders calls Inventory synchronously and blocks forever when Inventory is slow or down, a failure in Inventory can still cascade and take down Orders — this is a well-known failure mode called cascading failure. Real fault isolation requires deliberate patterns: timeouts, circuit breakers, bulkheads, and fallback behavior, not just the fact that the services run in separate processes.

How do transactions work across microservices if there's no single ACID commit?

The common pattern is a saga: a sequence of local transactions, one per service, where each step publishes an event that triggers the next step, and if a later step fails, the earlier steps run compensating actions to undo their effect (e.g., a "cancel reservation" call to reverse an "reserve inventory" call). It trades the simplicity of a single all-or-nothing commit for eventual consistency and considerably more application-level code to handle the failure and rollback cases.

What is the "distributed monolith" anti-pattern?

It's what happens when a system is split into separate services and deployables, but they're still so tightly coupled — via synchronous calls that must all succeed, or a shared database, or a release process that requires deploying several services together — that it has all the operational cost of microservices (network calls, more infrastructure, harder debugging) with none of the independent-deployability benefit. It's widely considered the worst of both worlds.

How many services is "too many" to start with?

There's no fixed number — the right question is whether each proposed service boundary corresponds to a real difference in scaling needs, release cadence, or team ownership. Teams that decompose along those real boundaries tend to end up with a handful of coarse-grained services; teams that decompose by entity or database table alone often end up with far more services than they can operate well, each one too small to justify its own deployment and monitoring overhead.

← Software Engineering & Cloud Studio

Concept Explainer · Software Engineering

Monolith vs Microservices

The real dividing line isn't codebase size or file count — it's whether your components ship, scale, and fail together, or independently across a network.

Ask a team why they're "doing microservices" and a common answer is some version of "our monolith got too big." But size was never the actual problem — a million-line monolith with clean internal module boundaries can be perfectly maintainable, and a "microservice" with 200 lines can still be a nightmare if it's tightly coupled to three others. The real distinction is the deployment boundary: a monolith is one deployable unit where every module talks to every other module through in-process function calls, while microservices are multiple independently deployable units that talk to each other over the network. Everything else — scaling, blast radius, debugging difficulty, transaction complexity — falls out of that one architectural choice.