System-Design

TL;DR System design has no right answers, only trade-offs chosen deliberately or chosen by accident. The skill is making the choice consciously Most decisions move along a few core axes: consistency against availability, latency against throughput, simplicity against flexibility, and build against buy A good design states its assumptions - expected load, acceptable latency, failure tolerance - because a design is only “good” relative to assumptions The most common self-inflicted wound is designing for scale you do not have. Complexity added for an imagined future is paid for every day until that future arrives, if it ever does Write designs down. A short document that names the options, the choice, and the reason is worth more than any diagram There is a particular kind of interview question, and a particular kind of blog post, that treats system design as a body of correct answers - as if there were a known-good way to “design a URL shortener” or “design a news feed” and the job is to recall it. This framing is actively harmful, because it teaches people that system design is about memorising solutions. ...

The views in this post are my own personal reflections on the industry, written in my own time. They are not about any specific employer, team, or colleague, past or present, and do not draw on any non-public information. “Best practice” is a phrase that should be treated with suspicion. What works for a fintech running 500 engineers rarely works for a five-person startup. The notes below are generic patterns drawn from public talks, books, and industry write-ups - always weighed against context, team size, and what the system is actually trying to do. ...