Architecture

Architecture is the set of decisions that are expensive to reverse, and the habits that keep those decisions visible while a team keeps shipping. This branch is not a tour of pattern names. It is where I put the notes about review cadence, service boundaries, events, and the coordination of work that crosses those boundaries.

System design is the prerequisite branch. A design can be sketched in a meeting and still be the wrong shape. Architecture is what remains after you have to live with that shape for a year: who is allowed to change it, how a review finds the decision, and which pattern you adopted because the alternative was worse, not because the diagram looked clean. Distributed systems sits further back. If a post here talks about a saga or a mesh, it assumes you already know why a network call is not a function call.

The published posts start with a review loop a team can sustain, then move through the network layer, event-driven tradeoffs, and a .NET workflow that separates commands from the long-running process around them. Read the review loop even if you came for the patterns. Most of the later pain is a decision nobody wrote down.

These pages are allowed to stay opinionated. I mark them budding when the tradeoff still moves under me, and evergreen when I have repeated the advice often enough to keep it. If you disagree with a page, the useful response is a more precise failure, not a longer list of patterns.