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

Part 16 of 17 · ~1 min

The Question That Actually Decides It

"Are microservices better" was never actually the question worth asking. The real one is narrower, and a lot more answerable: is there a specific piece of this system that needs to scale, ship, or be owned on its own terms badly enough to be worth everything covered above — the network calls, the eventual consistency, the extra services to run and keep patched?

If you're a small team building something new, you'll ship faster as a monolith almost every time, and Furrow is a fairly clean proof of it: the version of the company that got a real, paying product out the door in its first four months was one codebase and one database, run by four people who settled disagreements by turning their chairs around, not by filing a ticket against another team. Nobody was fighting over a shared release calendar yet, and nothing in the traffic graphs was begging for one particular piece to scale on its own. The teams that actually get their money's worth out of microservices, Furrow included, tend to be the ones who already had a working monolith and ran headfirst into a specific, named problem — one team stuck waiting on another team's deploy window, a database visibly buckling under one predictable weekly spike — rather than the ones guessing at a scale they don't have yet from an empty repository. Get the pain first, then split for it; a modular monolith with boundaries people actually respect, followed by a strangler-fig extraction once something is genuinely straining, gets you there with far less risk than jumping straight to four services or gambling on a full rewrite.