Microservices vs. Monolith: The Trade You're Actually Making
Part 3 of 17 · ~2 min
What Splitting Actually Buys You
Furrow's argument for splitting, when it finally happens, isn't abstract. It comes from four specific, felt problems, and each one maps to a real benefit:
Independent deployment. The Billing team wants to ship a fix to how mid-cycle plan changes get pro-rated — twice in one bad week, because the first fix was itself buggy. In the monolith, that means redeploying Harvest and the delivery-routing code too, whether they changed or not, because there's only one deployable unit. Once Billing is its own service, it ships that fix on its own clock, and nobody on Fulfillment even notices it happened.
Independent scaling. Harvest's traffic and Billing's traffic have almost nothing in common. Harvest gets hammered for about two hours every Wednesday night, when forty-some partner farms all upload their weekly counts before the order-lock deadline. Billing barely notices Wednesdays — its spike is the first of the month, when a wave of plan changes and card updates lands at once. In the monolith, scaling up for Wednesday night means scaling everything, including the parts sitting idle. Split apart, Harvest can run six instances on Wednesday and one the rest of the week, and Billing can do the opposite on the first.
Team autonomy. The Farm Partnerships team, who own the harvest-matching logic that decides which farm supplies which zip code, want to try a proper optimization pass instead of the greedy first-fit the monolith currently does — and the tool that's actually good at that kind of optimization problem isn't the language the rest of Furrow is written in. Inside one shared deployable, that's a hard no. As its own service, Farm Partnerships can write it in whatever gets the job done, and nobody outside that team has to care.
Fault isolation, in principle. A bug in the delivery-route optimizer that pegs a CPU at 100% shouldn't take down checkout. In the monolith, it can — one process, one crash radius. Split apart, it doesn't take Subscriptions down with it automatically. The word "automatically" is doing real work in that sentence, and the resilience-patterns chapter later on is entirely about what it actually takes to make that true instead of just hoped-for.