Microservices vs. Monolith: The Trade You're Actually Making

Part 2 of 17 · ~2 min

What Each One Actually Is

Furrow starts, like almost everything does, as one codebase. SubscriptionsController figures out who's getting a box this week, HarvestLot tracks how much of each vegetable the partner farms have actually got, Charge runs the weekly billing. All three live in the same repository, deploy together as one process, and talk to each other the cheapest way two pieces of code can talk: a function call. When checkout needs to know whether there's still lettuce for zone 3, it calls HarvestLot.reserve(lot_id, quantity) directly, in-process, and gets an answer in microseconds because nothing left the machine. There's exactly one Postgres database behind all of it, and every table in it is fair game for every part of the app — that's the actual definition of a monolith: one codebase, one deployable unit, and usually one database that anything in the codebase can reach into.

Microservices split that same functionality into pieces that each get deployed on their own, each own their own slice of data, and talk to each other over the network — HTTP, gRPC, a queue — instead of calling a function. The part that actually matters isn't "more than one process." Plenty of monoliths run as more than one process (a web server and a background-job runner, say) without being microservices in any meaningful sense. What makes it microservices is that each one holds its own slice of data exclusively and can be built, shipped, and scaled without asking anyone else's permission or waiting on a coordinated release. The moment two "services" still reach into the same database table, you've paid for the network calls without buying the independence that was supposed to be the whole point — Furrow will find this out the hard way in a few chapters.

Neither of these is really "an architecture" on its own — they're two ends of a spectrum, and almost nothing real sits cleanly at either end. Furrow, by the end of this reference, is a "microservices" system with one service that still quietly shares a table with another, because splitting it further genuinely wasn't worth it yet. Most of what follows isn't really about declaring a winner. It's about what actually changes, concretely, as you slide a system along that spectrum — and about the fact that sliding it back is sometimes the correct move too.