You Built for a Scale That Never Came
Every capability you architect for is a goad you agree to carry, and you agree long before anyone asks you to.
लहानपण दे गा देवा · Give Me Smallness
लहानपण दे गा देवा । मुंगी साखरेचा रवा ॥ १ ॥
ऐरावत रत्न थोर । त्यासी अंकुशाचा मार ॥ ध्रु ॥
ज्याचे अंगीं मोठेपण । तया यातना कठीण ॥ २ ॥
तुका म्हणे बरवें जाण । व्हावें लहानाहूनि लहान ॥ ३ ॥
Give me smallness, God. The ant gets the grain of sugar. Airavat is a great jewel, and for exactly that he takes the goad. Whoever carries greatness carries hard suffering. Tuka says: understand this well — better to become smaller than the smallest.
I drew the diagram
Fourteen services. Kafka in the middle. Per-service Postgres so nobody shares a database, a mesh, distributed tracing, blue-green deploys, two Kubernetes clusters in two regions because someone in a room in 2023 said four nines and nobody wrote down why.
I can defend every one of those boxes. I did defend them in design review, and I won. Each has a document behind it and the documents are good. This was not cargo cult. This was a competent architect doing what we are trained to do, which is build for the load you were told to expect.
Peak traffic was four hundred requests a second. It never went higher, and the second region never carried a single user in anger. Three years in, I was spending most of my week on the machinery instead of the product, and when my VP asked why a simple feature took five weeks, I had no honest answer ready.
I had built an elephant. Nobody told me elephants come with a goad.
Nobody itemised the bill
Fourteen services is fourteen deploy pipelines, fourteen dependency streams, fourteen alert configurations, and a tracing bill that exists so a human can reconstruct what one stack trace used to give for free. Someone has to stay current on Kafka's failure modes. That someone was me, and the hours came out of the domain knowledge I was hired for.
Here is the trap, and it is not incompetence. Every piece was justified in isolation and still is. There is no meeting where the sum gets presented. Capability is procured one defensible decision at a time, and the tax arrives as a single undifferentiated pressure everyone experiences as simply being busy. You do not notice you are carrying an elephant. You notice you are tired.
And the tax scales with what you provisioned, not what you serve. I was not paying for eleven thousand users. I was paying every week, in engineering hours, for the ten million I was told to be ready for. They never came. The bill came anyway.
Robin Sloan built a messaging app for his family in 2020. Four users, zero churn. Five years on it still runs, and his explanation is one line: these apps "are allowed to just: be finished." No mesh, no cluster, no upgrade treadmill. It outlived products with a thousand times its budget.
Getting small is harder than getting big
I tried to unwind it. That work is worse than building it, and nobody warns you.
Collapsing fourteen services into four is a migration with no demo at the end. It photographs badly and appears on no roadmap as a win. Every service you fold in belongs to someone who will read the merge as a verdict on their judgement, and sometimes it is. The guarantees you quietly relied on across boundaries must be found and made explicit before you can move anything, so the archaeology takes longer than the change.
You will be asked, in a room, why you are undoing work the company paid for. I was. I had no good answer that fit in one sentence, and that is the real reason most of this never gets unwound.
Adam Waxman's essay on single-user software put this back on the front page last week. His fitness app took a weekend and adjusts his smoothie portions to that morning's run, which no commercial product will do for him. He is right that build cost has collapsed. What he never has to reckon with, because he started at the correct size, is the cost of arriving there from the wrong one. Greenfield small is a weekend. The retreat is a year. And in his own comment section somebody is paying two thousand dollars a year to host software for one person, on infrastructure sized for a company, having just read an essay about not needing scale.
Where Tuka comes in
Tukaram asks for the thing no architect asks for in review: "लहानपण दे गा देवा" (give me smallness, God). Not right-sizing, which is the word we use when we want credit for restraint without losing status. Smallness, outright, as a gift.
The second line is a better architecture principle than anything in our literature. "ऐरावत रत्न थोर । त्यासी अंकुशाचा मार" (Airavat is a great jewel, and for exactly that he takes the goad). The elephant is not goaded despite being magnificent. He is goaded because he is. Capability summons the control apparatus. The mesh exists because the services exist, and the services exist because of a diagram I drew for ten million users in 2023.
Then the closing line, which is the instruction and not just the diagnosis: "तुका म्हणे बरवें जाण । व्हावें लहानाहूनि लहान" (Tuka says: understand this well — better to become smaller than the smallest). Not smaller as a virtue performed for its own sake. Smaller because size is the thing being taxed.
You do not have to unwind three years. Take the single most expensive capability you carry, the one whose operational cost is highest and whose triggering condition has never once occurred. Put a real number on both, and make the sum visible in a room exactly once. Nobody is going to kill the elephant. Someone might finally notice the goad.
Do that every quarter and you will not become small. You will stop getting bigger by default, which is the entire discipline. The future is architected, not generated, and architecture means choosing what not to build.
Sources
- Adam Waxman, Software for One, and the Hacker News discussion it drew (250 points).
- Robin Sloan, An app can be a home-cooked meal (2020), and the follow-up five years later, Five years of home-cooked apps.
- The abhanga is Tukaram Gatha 716, लहानपण दे गा देवा.
Chetan Dhandal