Architecture & Patterns68 min total · 17 parts
Microservices vs. Monolith: The Trade You're Actually Making
Part 13 of 17 · ~2 min
The Modular Monolith Middle Ground
There's a real middle ground Furrow could have tried before splitting anything: a modular monolith — still one deployable, still one database, but internally organized into modules with genuinely clean boundaries between them, talking to each other through defined interfaces instead of reaching into each other's internals, with each module's own tables nominally off-limits to every other module even though they physically live in the same database.
| Microservices | Modular monolith | Unstructured monolith | |
|---|---|---|---|
| Deployable units | 4 (for Furrow) | 1 | 1 |
| Databases | 1 per service, physically separate | 1, but each module is expected to stick to its own tables | 1, wide open to any code that wants it |
| What actually stops a boundary violation | The network — there's no table sitting there to reach into from outside | Reviewers and lint rules, when people bother to enforce them | Nothing |
| Scale or ship any one piece on its own? | Yes | No | No |
| Day-to-day running cost | Highest | Lowest | Lowest |
What a modular monolith buys you is most of the organizational payoff without most of the distributed-systems bill: a team can work inside its own module without tripping over somebody else's code, it's obvious where a given piece of logic is supposed to live, and none of it costs a network hop, a saga, or a trace to debug, because the request in question genuinely never left one process. What it doesn't buy you is a guarantee — its walls hold up only as long as reviewers keep enforcing them, and nothing stops a rushed change on a Friday afternoon from reaching straight into a module that isn't its business. Get that discipline actually right for a while, though, and splitting later gets a lot cheaper, because the module seams you've been living with tend to sit close to where the real service seams belong.
Furrow, in hindsight, could have gotten a real chunk of the way there with disciplined modules well before the Wednesday-night database pileup forced the actual split. It didn't — not because modular monoliths are a bad idea, but because nobody was enforcing the module boundaries with anything sharper than good intentions, and good intentions are exactly what stopped holding once the deadline pressure showed up.