System Design

System design is the practice of choosing a shape for a system before the shape chooses you. This branch collects the decisions I keep meeting in design reviews: how traffic is admitted, how trust is decided, and which failure you are willing to show a user. It assumes you have already looked at distributed systems, because most of these answers are a stance on consistency, capacity, or identity rather than a new algorithm.

The posts here are ordered as a reading sequence, not as a ranking of importance. Rate limiting comes first because it is the smallest distributed coordination problem that still breaks when you add a second instance. Zero trust comes next because the perimeter you thought you had usually disappeared at the same time the system became a set of services. Later notes will hang off this trunk when I have something I have actually operated.

You do not need to read the whole path to use one of these pages. Each post says what to read first. If that list is empty, the page stands on its own. If it is not, the link is a real page, not a gesture at a topic. I would rather leave a branch short than invent a paragraph so the outline looks finished.

Treat the maturity badge as a claim about the writing, not about you. Budding means the model is one I am using and still expect to correct. When I upgrade a page, the tended date changes and the badge should change with it.