Skip to content
Shipworthy

System Design

This hub explains system design from first principles: how services scale, stay available and stay correct when parts of them fail. It covers load balancing, caching, replication, sharding, queues, idempotency and rate limiting, and the trade-offs between consistency, latency and cost that connect them all.

It is written for two kinds of reader. The first is preparing for system design interviews and wants to understand the patterns well enough to reason through any prompt. The second is designing a real system and wants to think clearly about it, rather than copying an architecture diagram from a company a thousand times their size. The same ideas serve both. The difference is that production also has a budget and an on-call rota.

The approach is to start from the problem, explain the mechanism, and name the cost. Every pattern has a trade-off, and every post says what it is. Facts about specific systems, such as how DynamoDB partitions data, how Postgres replicates, or how a large social feed was built, are checked against official documentation, papers and engineering blogs, with the sources listed at the end of each post. Examples tie back to systems you can run yourself, including the serverless stack behind this site, so you see the patterns at small scale as well as large.

Where to start: system design interview prep, covering the twelve patterns that matter, is the map of this hub. It gives each pattern the problem it solves, how it works, what it costs, a real example and how to explain it in an interview. Then read idempotent writes in DynamoDB with a guard item, which takes one of those patterns all the way to working code. The Software Engineering and DevOps & Cloud hubs cover the practical side of the same ideas.

All posts