What system design is, what interviews assess, and the recommended path through this study track.
A four-step method for open-ended design questions: agree the scope, outline the design, go deep where it matters, and review the trade-offs.
How a system grows from a single machine to many, one bottleneck at a time, and the order in which real teams add each piece.
Turning vague requirements into rough numbers for traffic, peaks, storage and bandwidth, so the design fits the real size of the problem.
Scaling up vs scaling out, why servers must be stateless, and why the database is always the next bottleneck.
Splitting data across machines when one database is no longer enough: choosing the partition key, the methods, and what partitioning costs.
A hashing scheme that spreads data across a changing set of servers while keeping remapping to a minimum when a server joins or leaves.
Why a replicated system must choose between consistency and availability when the network fails, and how real systems make that choice.
Checking whether an item is in a set using a few bits per item, with no false negatives and a tunable false positive rate.
How caches speed up reads, the common caching patterns, and how to keep a cache consistent with the database or repair it when it drifts.
Making cached data and permissions expire safely: choosing TTLs, expiry behaviour in caches and databases, and leases for caches and locks.
Capping how many requests each client may send, where the limiter sits, the five common algorithms, and keeping limits accurate across many servers.
Creating IDs that never collide across many machines: auto-increment, random UUIDs, ticket servers, Snowflake and UUIDv7.
Why time-ordered IDs keep database indexes compact, and how to rebuild an index or change an ID scheme on a live system during low traffic.
A distributed key-value store step by step: partitioning, replication, quorums, failure handling and on-disk storage, as in Amazon Dynamo.
Practical techniques to speed up an application, from measuring and indexing to fixing N+1 queries, pagination, caching, queues, the network and the frontend.
Why opening database connections is expensive, how a pool reuses them, and how to size it with the cores times two rule, since too many connections makes things slower.