You Can’t Make Bean Soup
I became a vegetarian about 28 years ago. Early on, I called my mother to ask how to make bean soup. She started walking me through her recipe, and when she got to a certain step — “and then you need bacon grease” — I said, “Uh, can’t do that.”
She froze for a moment. Then, almost angrily:
“Well… well… then you CAN’T MAKE BEAN SOUP.”
I still laugh about it. But the more I’ve thought about it over the years, the more I think my mom wasn’t being stubborn. She was making an ontological claim I’d accidentally challenged. Bacon grease wasn’t an ingredient in her recipe. It was part of the grammar of soup-making. Without it, you don’t get different soup. You get not-soup.
And I’ve come to believe that a staggering amount of what’s broken about the software we build for the world — the software you hit when you call an airline, argue with your insurance company, try to change a car rental, or dispute a utility bill — is a bacon grease problem.
The Computer Won’t Let Me Do That
Everyone has heard some version of this sentence. You’re on the phone with a customer service rep. You’ve asked for something that makes perfect sense to both of you. They’ve said, more or less, “I hear you, that’s totally reasonable.” And then:
“But the computer won’t let me do that.”
They’re not lying. The computer really won’t let them. The problem is upstream of the computer — upstream of the rep, upstream of the policy manual, upstream even of the system architect. It’s in a set of quiet commitments that got made decades ago about what a business transaction is, and it’s the same bacon-grease claim my mother made. Without ACID transactions, you don’t get different business logic. You get not-business-logic.
That’s not a technical argument I’m making. It’s a description of how the argument lands. Try, sometime, talking to an auditor or a compliance person at a large insurance company about eventual consistency. Watch their face. You won’t get disagreement. You won’t even get confusion. You’ll get a reception mode I’ve come to think of as does-not-compute — the same frozen beat my mother had before the bacon-grease ruling. They can’t place what you’ve said in any of the slots reception usually has. It’s not “I don’t understand.” It’s not “I disagree.” It’s “the thing you’re describing isn’t a variant of what we do; it’s a category error.”
I don’t blame them. Most teaching frameworks assume the listener will do one of three things: fail to understand, understand and reject, or understand and accept. There’s a fourth mode that almost nobody is prepared for, which is the one where the listener experiences the proposal as a challenge to the constraints of reality itself. You can’t argue about grammar. You argue in grammar.
Data on the Outside
The person who helped me see this most clearly is Pat Helland. Pat is one of the most important thinkers about distributed systems that almost nobody outside the field has heard of. I knew him a little back in his Microsoft Transaction Server days. He has a paper from ~2005 — Data on the Outside versus Data on the Inside — that I keep coming back to.
The distinction is simple and it changes how you see everything once you see it.
Data inside a transaction boundary is ACID: mutable, consistent, isolated, exists at a point in time. It’s the thing most people mean when they say “the data.” But data outside that boundary — messages, events, documents, records of things that already happened — is a completely different animal. It’s immutable. It’s identifiable. It’s versioned. It exists across time, not at a moment in time.
Helland’s insight is that a huge amount of what we’ve built over the last few decades has been about forcing outside-data to behave like inside-data. And a huge amount of what’s gone wrong has been the consequence of that force. Because real-world interactions are natively eventually-consistent. Disputes happen. Returns happen. Pricing corrections happen. A customer places an order, then calls and changes it, then calls back and changes it again. A claim is filed, denied, appealed, reopened, resolved, and then re-audited three years later in light of a regulatory change nobody saw coming.
None of that fits inside a transaction.
The sharper way to say it: transactional consistency is the in-the-code version of “the computer won’t let me do that.” ACID forces every variable to collapse into a consistent state right now. That means every rule has to pre-exist the encounter. The CSR can’t improvise because the database can’t improvise. The demon is written into the isolation level.
Rules That Show Up When They’re Needed
The alternative isn’t anarchy. The alternative is that rules get composed at the moment of encounter instead of pre-compiled for every case nobody anticipated.
Here’s a rule I’d love to see more of, stated in plain English:
If the price of the item when the customer placed the order is different from when they created the cart, fail. Unless the customer has been a VIP for ten or more years, the price change is within a certain time window, and the delta is under a certain threshold — in which case, honor the lower price and move on.
That rule can’t be compiled ahead of time. Or rather, it can be, but only by first anticipating that exact compound of conditions, which means every humane edge case has to be foreseen and written before it occurs. In practice, none of them are. The result is the software we live with.
Eventual consistency, event sourcing, and “data on the outside” are not just architectural patterns. They’re permissions. They’re permissions for the encounter to be the place where the rule actually lives — where the context of this specific customer, this specific moment, this specific change, is available to the reasoner. They let us build systems where the rental car clerk might actually be able to do the thing, because the system supports a reasoning step rather than forcing collapse into a single globally-consistent now.
Why I Think This Is Interesting Right Now
There’s a reason this has been rattling around in my head more than usual the last couple of years. We now have a new kind of ingredient in the kitchen.
The if/else demons aren’t going anywhere; computers literally are if/else. What I think is actually happening is that there’s now a second layer on top of the compiled rules where the un-anticipated cases can land without being forced through them. You can imagine a CSR who, instead of saying “the computer won’t let me do that,” says “let me look at this with my AI for a second.” (the new “let me check with my manager”?) And the AI isn’t bound by the rule-compiled-ahead-of-time because it can reason about the actual situation in front of it — including whether the compiled rule even makes sense for this case.
That’s not a fantasy. That’s a different relationship between the rules and the encounter. And it only works if the system underneath is the right shape — if it lets information live outside the transaction as much as inside it, if it preserves the events rather than collapsing them, if it gives the AI (and the human) something to reason about rather than a fait accompli to either pass or fail against.
I don’t think ACID is going away. I don’t even think it should. There are plenty of things — money transfers, seat reservations, inventory decrements — that genuinely want strong consistency, and I’m happy to let them keep it. What I’m suspicious of is the domain creep — the way transactional thinking escaped from where it was needed into places it never belonged, and became bacon grease. Became the thing where proposing to live without it doesn’t produce a different system but not a system.
I think we’re about to find out what the soup tastes like without the bacon. And maybe — for the people on the phone, who have perfectly reasonable requests, and who’ve been living with three decades of “the computer won’t let me do that” — that’s going to be a pretty good soup.
Thanks, Mom.