The Two Temples: Monoliths of Stone and Flickers of Light

There is a quiet, fundamental schism in how we build the small, critical services that keep our digital world from fading to black. It’s not a debate of language or framework, but of philosophy. It is the choice between building a temple of stone and tending a sacred flame. One is an edifice of immense, reassuring permanence. The other is a flickering, vital light that must be constantly fed. Both serve the same god of reliability, but their rituals could not be more different.

The monolithic service, the temple of stone, is a monument to upfront effort. You quarry the logic, shape the dependencies, and mortar every block into a single, formidable structure. Its reliability is that of a mountain; it is simply there. When it runs, it is a self-contained universe. Its logs are the carvings on the walls, telling a single, unified story. A failure here is an earthquake—a singular, catastrophic event that brings the entire edifice down, but one whose epicenter is, at least, undeniable. You don’t wonder *which* stone is crumbling; the whole temple is shaking.

In contrast, the service built from micro-functions—be it a patchwork of serverless triggers or a careful choreography of queues and workers—is the tending of a flame. Its reliability is not in its mass but in its process. The system is a constellation of tiny, ephemeral lights, any one of which can flicker and die without plunging the entire system into darkness. A single request might leap like a spark across a dozen such lights, each doing its minuscule part. Its failure is not a quake but a draft in the temple—a single spark fails to catch, and the chain of light is broken. The challenge is not rebuilding a wall but finding which wick needs trimming.

The stone temple offers the comfort of a known entity. You back it up as a whole, you monitor its monolithic heartbeat, and its operational story is a linear scroll. The flame-tender’s world is one of distributed complexity. Reliability is achieved through redundancy and retries, not mass. Backups are less about a single point-in-time snapshot and more about the integrity of the event stream that feeds the lights. Logging is no longer a single narrative but a thousand fragmented testimonials that must be pieced together to understand the path of the spark that went missing.

Neither approach is inherently superior. The stone monolith can become a labyrinth, impossible to modify without bringing down a wall. The sacred flame can become a bewildering firestorm of inter-dependencies, impossible to reason about without a map of its entire constellation. The choice is, and always will be, a question of temperament. Do you seek the profound silence of a standing stone, or do you find solace in the rhythmic, never-ending ritual of feeding the fire? Both are acts of faith, built to keep the darkness at bay.

Notes & further reading

A few pages I came back to while writing this: