Can You Scale a Story?

I brought a diagram to the meeting.

It was a row of small boxes passing notes to each other. A webhook arrives saying money changed hands. The first box writes down the order, immediately says “got it,” and walks away. A second box, later, picks up the note, looks up the full order, and writes two more notes: one about the customer, one about what to deliver. A third box handles the customer. A fourth delivers the product. No box does more than one thing. No box waits for the box after it. No box knows how the whole thing ends.

This was for a platform I helped build, the kind of thing that takes money on one side and spits out digital products on the other with no human in the loop. Order in, product out, nobody awake. The diagram was how it would happen.

Someone studied it for a while and said: we don’t need all that. We do things in a simpler way, one that will work forever.

The room nodded. Notice how good that sentence feels. Not “a way that works.” A way that works forever. Hold that word. We are going to need it at the end.

Is your system a story?

Here is the quietest true thing about the simpler way, the one nobody in that room said out loud. It is not simpler to run. It is simpler to read. A synchronous system is a story. A request comes in, you do the first thing, then the second, then the third, and you hand back an answer. You can put a finger on the top line and slide it to the bottom and you will have watched the entire life of that request, in order, beginning to middle to end. One thread. A single path with a driver who picks the destination and takes you there. And a person who can follow a thread like that feels something close to safety.

Is that feeling why “simpler” wins almost every argument it walks into? You cannot really argue with something you can hold whole in your head. And my diagram, on purpose, could not be held whole in anyone’s head. There was no single line to slide a finger down. There was no narrator. To understand it you had to accept that at no single moment does any one place know the whole story. The flow was not driven by a plan. It was driven by events, each box reacting to a note left by the last, nobody steering.

When “got it” doesn’t mean “done”

One of them caught the part that always makes people flinch. Look here, they said. The first box tells the outside world “got it” before a single thing has been delivered. You are lying to the customer. You are reporting success on work you have not done.

Is it a lie? In a story, when you say “ok,” you mean “done.” But the note was already on the queue, and the queue does not forget, and a worker would keep retrying that note until the product was truly delivered. “Got it” never meant “done.” It meant: I will not drop this. Can you hear the difference if you are still reading the system as one continuous tale told by one teller?

They chose the story. And for a while, the story was true.

How does a “forever” die?

It worked at launch. It worked the week after. Then the thing did exactly what we had all said we wanted. It grew. More orders, more customers, more to deliver, and one part of the flow began to sweat.

Here is the autopsy, and it is shorter than you would expect. You scale a synchronous system synchronously. Everything is chained into one thread, so when one link gets hot, you cannot feed only that link. You feed the whole chain. You buy a bigger machine, and the bigger machine runs every step, including the steps that were never tired, just so the one tired step can breathe. You pay for the entire story to be told faster because you have no way to tell only the slow part of it.

A “simpler way” does not die with a crash at 3am. It dies with an invoice. Every month, a bill for capacity that mostly sat idle, paid so that one corner of the system could keep up. “Works forever” had quietly turned into “works as long as you keep buying a bigger box for everyone.”

So we paused. We cut the thread. We moved the work onto queues, and suddenly we could grow the hungry worker on its own and leave the rest of them small. We stopped buying a bigger machine for the whole flow. We started spending exactly where the load was, the way you water the one plant that is wilting instead of flooding the entire garden.

The thread you follow is the block you grow

And somewhere in that migration, a question I should have asked in the meeting finally arrived.

What if the property that made the synchronous system so easy to follow was the exact same property that made it impossible to scale a piece of? The single thread was the comprehension. The single thread was also the coupling. Were they ever two different things, or one thing wearing two faces? Being able to read it as one story, and being forced to run it as one block. Is the reason you can follow it end to end not also the reason you have to grow it all at once?

Can you scale a story? A story only works in order, whole, told by one voice. Let four workers tell four parts at four speeds and you can grow each part on its own, but what happened to the page where a single finger slides down and sees everything?

Were they ever afraid of complexity?

Were the people in that meeting ever really afraid of complexity? Look at the boxes again. Each one is simpler than the step it replaced. One job, no waiting, no knowledge of the ending. If complexity is how much each box has to hold, the queue version has less of it, everywhere. So what were they actually about to lose?

The narrative. The ability to follow. And doesn’t losing the ability to follow feel exactly like the thing getting worse, even when every individual piece has gotten smaller?

“I can’t follow this” sounds like a sentence about the code. But what if it is a sentence about what the person is being asked to give up? The thread they want back is the same thread that has to be cut for the system to grow. So when someone asks for the thread back, what are they really asking the system to do?

Complexity only changes currency

Now notice what neither version escapes. The complexity did not move out. It moved. In the synchronous world it lived in the bill, in the ever bigger box, in money. In the asynchronous world it lives in your head, in the queues and the retries and the dead letters you now have to understand, in comprehension. You pay either way. The only thing you get to choose is the currency.

So what was “a simpler way that works forever,” all along, if not a decision about how to pay? It chose cash, so that no one in the room would have to pay in understanding. And for a while that is a wonderful trade. The cash leaves slowly, a little every month, and the understanding would have hurt all at once. It stays a wonderful trade right up until the month the cash stops being a little.

Did you want to follow it, or grow it?

So before you reach for the simpler way, the one that reads like a story and works forever, sit with one thing.

The system you can explain in one breath is the system you will pay to scale in one block. Did you want code you can follow, or code that can grow without you? When did it get so hard to have both?

And the next time someone says “I can’t follow it,” stay on the word follow for a second before you answer. Are they telling you the thing is broken? Or are they telling you, without knowing it, the exact place where the thread has to be cut?

Forever is a long time. How long did yours last?