System Design resources for developers

The course that made system design interviews learnable, working through designs for services like a URL shortener, a news feed, a messaging system and a video platform, each with the requirement gathering, capacity estimates and trade off discussion an interviewer expects.

The full path through system design preparation, from the building blocks up through advanced designs and practice. Follow it in order instead of assembling a curriculum from scattered blog posts.

The building blocks every design answer is assembled from: load balancers, caches, databases, replication, sharding, message queues, consistency models and the CAP trade off. Start here if the full design walkthroughs feel like they assume knowledge you do not have.

The follow on course, working through the real distributed systems that the standard designs are built from, including consensus, distributed storage and coordination. This is the material that separates a senior answer from a mid level one.

The recurring distributed systems patterns behind most designs, including write ahead logs, leases, heartbeats, quorums, segmented logs and consistent hashing. Learn the patterns once and you stop reinventing an answer for every question.

Service decomposition, inter service communication, data ownership and the failure modes that appear the moment a system stops being one process. Interviewers ask about the trade offs, not the diagram.

The named patterns that make service architectures survivable, including API gateway, circuit breaker, bulkhead, sidecar, saga, CQRS and event sourcing. Each one exists because someone lost a weekend to the problem it solves.

How systems actually scale, covering horizontal growth, statelessness, caching layers, database partitioning and the bottlenecks that appear at each order of magnitude. Focused on the reasoning an interviewer is listening for.

A compressed run through the system design round for when the interview is next week and the full course is not going to happen. Enough structure to stop you improvising.

A free, browsable index of system design concepts and worked questions, useful as a reference while you practise. A good way to judge whether the paid material is for you before paying for it.

Design prompts to work through under time pressure, which is the part of preparation everyone skips. Reading designs builds recognition, producing them builds the skill being tested.

How databases actually work underneath: storage engines, indexes, transactions, isolation levels and the relational versus non relational choice. The layer that makes system design answers defensible instead of hand waved.

Recommendations, data pipelines, and a lot of writing about how engineering teams are organised and tooled. Read it for the developer experience posts as much as the architecture ones.

Messaging at scale, real time presence, search and the slow work of migrating a large PHP codebase without downtime. Practical, honest about constraints, and closer to the problems a normal company actually has.

Real time matching, geospatial indexing, payments and the long running story of moving off a monolith. The problems are concrete and easy to picture, which makes this a good blog to start with if architecture write ups usually lose you.

Posts on storage, caching, data centres and the infrastructure behind products used by billions of people. Uneven, and the good ones are very good, particularly anything about how a system was migrated while staying online.

The most consistently readable engineering blog in the industry. Deep posts on networking, DNS, TLS, caching and database scaling, plus unusually candid incident reports. If you only follow one engineering blog, this is a strong pick.

Long form write ups of decisions taken at a scale most of us will never work at, which is exactly why they are worth reading. Streaming architecture, caching, chaos engineering and personalisation, usually with the numbers and the mistakes included.

What is actually happening below the query. Part one covers storage engines, B trees and log structured merge trees, so you finally understand why write heavy and read heavy databases are built differently. Part two covers replication and consensus. Dense, but it turns database choice from guesswork into reasoning.

Architecture books usually give you patterns. This one gives you the trade off analysis, which is the actual skill. It works through decomposing a monolith, splitting data ownership, and choosing between saga styles, and it refuses to hand you a right answer where none exists.

The honest book on services, including the long section on why you probably should not split yet. It covers the parts that actually hurt: breaking apart a shared database, testing across service boundaries, and the team structure that has to change alongside the architecture.

The course version of the System Design Interview books, built around the diagrams that made them popular, plus a large library of real world architecture breakdowns. Probably the best known paid system design course after the Grokking series.

Educative's system design course, built around a set of reusable building blocks that get assembled into each design, all inside an interactive browser environment with no setup. A widely used alternative worth comparing before you commit.

The graduate distributed systems course, with lecture videos, the paper reading list and the laboratory assignments where you implement Raft and a sharded key value store in Go. Genuinely hard, and the single best free thing in this area.