The Potter's Wheel and the Stamp Press: Two Philosophies of State Management
In the quiet, meticulous craft of keeping small services running, there’s a fundamental decision we make, often without realizing it: how to handle state. It’s a choice that shapes everything that follows, from our backup strategies to our recovery posture. Over the years, I’ve come to see this choice as a divide between two distinct philosophies, one embodied by the potter’s wheel and the other by the stamp press.
The potter’s wheel represents the philosophy of mutable state. Here, your system is like a lump of clay on the wheel. It is a single, live entity. You configure it, patch it, and update its packages in-place. The state evolves, accumulates history, and is intrinsically tied to the machine it runs on. It has a personality, shaped by every interaction, every package update, every tweak to a config file. Backing up such a system is like taking a photograph of the pottery at a specific moment—you capture its current form, but the process of creation is lost. Restoring from backup means trying to perfectly recreate a unique artifact, a snapshot of a living system. It’s an art, prone to the fragility of memory and the entropy of a running system.
In contrast, the stamp press is the philosophy of immutable state. The system is not a single evolving piece of clay, but a series of discrete, identical stamps. The application and its entire environment—the OS, the libraries, the configs—are built into a single, versioned artifact, like a master die. To deploy, you simply stamp out a new instance. The state that matters, the data, is strictly separated, stored externally in a database or object store. The server itself is stateless and, more importantly, disposable. If something goes wrong, you don’t repair the pottery; you throw the faulty stamp away and press a new, known-good one. Backups become vastly simpler: you guard your data and your stamp designs, not the individual running instances.
At first glance, the potter’s wheel seems more approachable for a small service. It’s how many of us started—spinning up a server and molding it to our will. It feels like craftsmanship. But this approach carries a silent tax. Each manual change is a potential source of drift, making the system a unique snowflake. Disaster recovery becomes a high-stakes archaeological dig, trying to piece together the exact conditions that made the system work. The stamp press, with its requirements for automation and disciplined separation of concerns, demands more upfront rigor. It feels less like hands-on craft and more like industrial design. Yet, this investment pays dividends in reliability and repeatability. It turns deployment and recovery from a delicate art into a predictable, mechanical process.
The choice isn’t always absolute. Many systems live in the grey area, perhaps with a mostly-immutable application container running on a mutable host OS. But recognizing these two archetypes helps clarify our intentions. Are we potters, valuing the tactile, direct control of a unique creation? Or are we stamp-makers, valuing the resilience and consistency of a replicable process? In the long-term stewardship of a service, the predictable, boring reliability of the stamp press often proves to be the quieter, more dependable anchor. It’s the difference between tending a singular, beloved but fragile vase and owning a machine that can produce a perfect new one on demand.
Notes & further reading
A few pages I came back to while writing this: