Why small services age well

Every service we run starts as a solution to one problem. Somewhere around the second year, most of them have quietly become solutions to six problems, three of which no longer exist.

The interesting property of a small service isn't that it does less. It's that its failure modes stay legible. When something breaks, you can still draw the whole thing on a napkin and find the seam.

The cost of a convenience

It is almost never one big decision that makes a service hard to operate. It's forty small ones — each individually defensible — that together turn a weekend project into something nobody wants to touch.

Prefer the boring option. Boring is a property that survives staff turnover.

What we keep

A single configuration file, a process supervisor that doesn't surprise us, and logs we can read without a query language. That's most of it. Everything else is an optimisation we can add later if a real number demands it.

The heuristics are unglamorous: one binary, one config, one volume for state, and a health check that a human can run from a laptop with curl.