Career & Craft
System Design
Architecting large systems from requirements and constraints — estimating scale, then choosing data stores, caching, queues, load balancing, replication and consistency trade-offs, and reasoning about bottlenecks and failure modes. It is how senior engineers turn vague needs into concrete architecture, and the centrepiece of senior interviews. There is no single right answer, only justified trade-offs.
Purpose
System design is turning vague requirements — 'build a URL shortener for millions of users' — into concrete architecture: data models, storage choices, caching layers, queues, scaling strategy, failure handling. It is the discipline of reasoning about systems before they exist, where changing your mind is still free.
When to Use It
Real work: designing a new service, reviewing a proposal, capacity-planning for growth, deciding whether that new feature needs a queue or a cron job. And interviews: system-design rounds are the centrepiece of senior hiring because they expose how a candidate weighs trade-offs under constraints.
Trade-offs
There is no single right answer — only trade-offs justified against requirements. The recurring failure mode is designing for imagined scale: the resume-driven Kafka cluster serving forty requests per minute. Numbers discipline the process; fashion corrupts it.
Implementation
Follow a repeatable arc: clarify functional and non-functional requirements; estimate scale (users, requests/second, data volume — envelope math); design the data model and APIs; sketch the high-level components; then address scaling, caching, failure modes and bottlenecks explicitly. Practise by designing known systems and comparing against published architectures.