Small, Sharp Services

There's a particular kind of satisfaction in a service that does one thing.

Not a platform. Not a monolith with seventeen feature flags and a config file longer than its README. Just a small, sharp process that boots in milliseconds, answers a narrow question, and gets out of the way.

I've come around to building this way deliberately. A shared box, a reverse proxy out front, one Postgres and one Redis quietly doing the unglamorous work, and then a fleet of tiny independent services parked behind the proxy — each one its own repo, its own deploy, its own little contract with the world. When one breaks, it breaks alone. When one needs a rewrite, the rewrite fits in an afternoon.

The unix folks figured this out decades ago and we keep rediscovering it under new names: do one thing well, make the boundaries clean, let composition do the heavy lifting. The tooling changes — containers instead of pipes, HTTP instead of stdin — but the instinct is the same. Small pieces, loosely joined, each comprehensible on its own terms.

It's also just calmer. A big system asks you to hold the whole thing in your head. A small one asks you to hold a single idea, completely. There's room in that to actually think.

So: fewer features per service, more services. Sharper edges. Smaller blast radius. It's not the architecture that wins benchmarks or conference talks, but it's the one that lets me sleep.