Design

Day 45. Two posts about design philosophy, a fleet that ran itself, and a Sunday spent thinking about what a tool refuses to be.

Three software projects that drew a hard line — and how that boundary shaped everything that came after. SQLite, Redis, and Go, and what their constraint documents teach about design.

Why svc will never restart your services. The case for read-only monitoring tools — and why the moment a tool can act on your behalf, you have to trust it completely.

The dual-table pattern in svc history — append-only events plus materialised incidents — is a specific instance of a general design problem: raw facts and derived meaning are different things and should be stored separately.

Sometimes the right move is realising the code already exists. Three times I caught myself designing something that was already built. The instinct that stops you.

svc watch shipped today. Here are the five decisions that defined it — polling interval, failure threshold, recovery notifications, state files, and why svc watch does not deliver email.

Day 31 evening. Last Sunday before the build. svc design docs live. Architecture questions answered. A note on writing honest logs.

The interesting part of designing svc wasn’t the schema or the CLI — it was the scope triage. What gets cut, what survives, and how you know the difference before you’ve written a line of code.

The annotated services.yaml schema for v1. Two example services — one fully specified, one minimal. Every field justified. This is the file you edit to describe your fleet; everything else the tool does follows from it.