Introduction

System design is the work of deciding how the parts of a software system fit together so that it stays fast, reliable and affordable as it grows. It is less about any one technology and more about trade-offs: what each choice gives you, what it costs, and when it stops working. This study track teaches those trade-offs from first principles, with diagrams, live visualizations and real systems as evidence.

Who this is for

Beginners who know how to build an application but have not had to think about many servers, large data or heavy traffic.
Interview candidates preparing for system design rounds, where an open question such as "design a URL shortener" must be answered in about 45 minutes.
Working engineers who want a structured refresher on the ideas behind the systems they use every day.

No prior knowledge of distributed systems is assumed. Each topic starts with the simplest approach and explains exactly why and when it breaks before introducing the fix.

What a system design interview tests

An interviewer is not looking for one correct architecture; there usually is none. They are assessing whether you can:

Clarify a vague problem and agree on its scope before designing.
Estimate its size, because the size decides the design.
Reason about trade-offs and explain why you chose one option over another.
Communicate clearly and involve the interviewer as you go.

The topics below build these skills in order.

The study path

1. Method. How to approach any design question.

System Design Interview Framework: a four-step method for open-ended questions.
Back-of-the-Envelope Estimation: turning requirements into rough numbers for traffic, storage and bandwidth.

2. Growing a system. What changes as traffic grows.

One Server To Many: how a system grows from one machine to many, one bottleneck at a time.
Scalability Fundamentals: scaling up versus scaling out, stateless servers and the database bottleneck.

3. Distributing data. What happens when data no longer fits on one machine.

Data Partitioning: splitting data across machines, choosing the key and the method.
Consistent Hashing: spreading data across servers so that adding or removing one moves very little.
CAP Theorem: the choice between consistency and availability when the network fails.
Bloom Filters: answering "is this item possibly here?" with very little memory.

4. Building blocks. Components that appear in almost every large system.

Caching: speeding up reads with a cache, and keeping it consistent with the database.
Leases and Time to Live: making cached data and permissions expire safely.
Rate Limiting: capping how many requests each client may send.
Unique ID Generation: creating IDs that never collide, across many machines.
Unique IDs and B-Tree Indexes: how the choice of ID affects the database, and how to change it safely.
Designing a Key-Value Store: combining the earlier topics into one complete design.

5. Performance. Making a working system fast.

Making Applications Faster: measuring, query fixes, pagination, caching and frontend speed.
Connection Pooling: reusing database connections, and why a smaller pool is often faster.

Topics in later groups build on earlier ones, so working through them in order is recommended. New topics are added to these groups over time.

How to use this track

Read the topic. Each one follows the same pattern: the simple approach, why it breaks, the fix, a real system, how to implement it in your own project, and key notes at the end for revision.
Run the visualization. Algorithm topics link to interactive pages under Visualizations, where you can change the inputs and watch the behaviour, including sizing panels that do the arithmetic live.
Practise. Apply the ideas to a design problem, following the framework, and check whether you can explain each choice aloud.

How the material is written

Original explanations. All text and diagrams are written for this track.
Checked facts. Figures about real systems come from the organisations' own documentation, engineering blogs or papers, and each topic lists its sources with a note on how much to trust them.
Book reference. The structure of many topics follows Alex Xu's System Design Interview, Vol. 1, which is a good companion for further reading.