TodayTools

System design flashcards

Plan apps that stay fast and reliable as users grow.

Donate
Beginner friendly, starts from zero
Section
How to study
0
System designStart from zero · 1 of 12

What is system design, in one plain sentence?

System design is planning how the parts of a big app fit together, so it stays fast and keeps working when millions of people use it at once.

Not writing the code, planning the building.
Show again
12 left
Got it

Tap to turn over. Swipe right if you know it, left to see it again.

All topics

What you will learn

  1. Start from zero

    • What system design is4 cards
    • Building blocks4 cards
    • Measuring a system2 cards
    • Getting started2 cards

  2. Core basics

    • Requirements and scope3 cards
    • How a request travels2 cards
    • Caching and CDNs2 cards
    • Performance numbers and estimates3 cards
    • Scaling servers3 cards
    • Storing data4 cards
    • APIs and uploads2 cards
    • Reliability and security basics2 cards

  3. Next steps

    • Replication2 cards
    • Sharding and ids4 cards
    • Consistency trade-offs3 cards
    • Caching patterns3 cards
    • Queues, logs and delivery3 cards
    • Traffic control and the edge3 cards
    • Real-time updates and safe retries2 cards
    • Search, capacity and disaster recovery3 cards

  4. Go deeper

    • Architecture styles3 cards
    • Distributed transactions2 cards
    • Resilience and multi-region3 cards
    • Observability and SLOs3 cards
    • Storage and coordination internals4 cards
    • Design interview problems6 cards
    • Hot spots and data pipelines2 cards

Final test and certificate

10 questions drawn fresh from the whole topic, about 15 minutes. Sign in, score 80% or more and get a free certificate with your name and a public check link anyone can open, such as an employer or a teacher. Not signed in? Try a practice test from the cards.

Take the final test

About these cards

  • Reviewed 26 October 2026
  • CoversVendor-neutral concepts, checked October 2026HTTP per RFC 9110, UUIDv7 per RFC 9562Examples: PostgreSQL 18, Redis 8
How these cards are made

System design at a glance

System design is planning how the parts of a big app fit together so it stays fast and reliable as it grows.

Like a food stall growing into a busy restaurant: more cooks, a host to seat guests, a shelf of ready dishes and a rail of order tickets.

Words you will meet

Server
A computer that waits for requests and sends back answers
Database
Where the app's data is stored safely
Cache
Fast memory that keeps copies of popular answers
Load balancer
The part that shares requests between servers
Latency
How long one request takes
Availability
How often the system works when people need it
Queue
A waiting line of jobs for workers to pick up
Redundancy
Keeping spare parts ready so one failure does not stop everything

The steps

  1. 1. Start from zero (12 cards): What system design is, the parts of a big app in plain words, and how to sketch your first design.
  2. 2. Core basics (21 cards): Requirements, latency, scaling, load balancers, caches, CDNs, databases, indexes and estimates.
  3. 3. Next steps (23 cards): Replication, sharding, consistent hashing, CAP, queues, caching patterns, rate limits and races.
  4. 4. Go deeper (23 cards): Microservices, events, outbox, sagas, resilience, observability, SLOs and classic designs.
All 12 cards in Start from zero
What is system design, in one plain sentence?
System design is planning how the parts of a big app fit together, so it stays fast and keeps working when millions of people use it at once.
What problem does system design solve?
An app on one computer is fine for a few friends. When thousands arrive at once it slows down, crashes or loses data. System design plans for that crowd before it hurts.
Where do you already meet system design in daily life?
Booking train tickets the minute sales open, a festival sale on a shopping app, or a cricket final streamed to millions: each only works because someone designed for the rush.
What everyday thing is system design like?
A food stall growing into a busy restaurant: more cooks (servers), a host who seats each guest (load balancer), a shelf of ready dishes (cache) and a rail of order tickets (queue).
What are a client, a server, a request and a response?
A client is the app or browser on your phone. A server is a computer that waits for requests, messages asking for something, and sends back a response.
What are a database and a cache?
A database stores the app's data safely, like users and orders. A cache keeps copies of popular answers in fast memory, so the database is asked less often.
What are scaling and a load balancer?
Scaling means growing to handle more users: a bigger machine, or more machines. A load balancer sits in front and hands each request to a server that is free and healthy.
What are latency and throughput?
Latency is how long one request takes, often in ms (milliseconds, thousandths of a second). Throughput is how many requests the system handles each second.
What are availability, a single point of failure and redundancy?
Availability is how often the system works when needed, like 99.9 percent. A single point of failure is one part whose breakdown stops everything; redundancy means keeping a spare ready.
What are an API, a queue and a worker?
An API is the set of web addresses apps call to ask a server for things. A queue is a waiting line of jobs, and a worker is a program that takes jobs from it one by one in the background.
What do you need, and what is your first tiny win?
Nothing to install: pen and paper is enough. Draw any app you use as boxes and arrows: the client asks the server, and the server reads the database. That sketch is a system design.
What will you be able to do after this topic?
Sketch a design for an app with millions of users, pick the right database and cache, find what can break, estimate how many servers you need, and explain your trade-offs in an interview.
System design cheatsheet

Latency numbers (rough)

  • L1 cache reference ~1 ns
  • Main memory reference ~100 ns
  • Read 1 MB sequentially from memory ~3 to 10 us
  • SSD random read ~16 to 100 us
  • Same-zone network round trip ~0.5 ms
  • Redis GET over the network ~0.5 to 1 ms
  • Indexed DB query ~1 to 10 ms
  • Cross-continent round trip ~100 to 200 ms

Availability

  • 99% (two nines) ~7.3 h down / month
  • 99.9% (three nines) ~43.8 min / month
  • 99.95% ~21.9 min / month
  • 99.99% (four nines) ~4.4 min / month
  • Serial deps: A x B 99.9% x 99.9% = 99.8%
  • Parallel copies: 1 - (1-A)^2 99% each -> 99.99% together

Building blocks

  • Load balancer (L4 / L7) Spread traffic, health checks
  • CDN Cache static and edge content near users
  • Redis / Memcached In-memory cache, counters, locks
  • Read replica Scale reads, standby for failover
  • Shards Scale writes and storage by key
  • Queue / log (SQS, Kafka) Decouple, buffer, retry
  • Object storage Files, media, backups
  • Search index Full-text and faceted queries

Trade-offs

  • Consistency vs availability Under partition (CAP)
  • Latency vs consistency Even without partition (PACELC)
  • Normalise vs denormalise Write simplicity vs read speed
  • Fan-out on write vs read Fast reads vs cheap writes
  • Push vs pull updates Freshness vs connection cost
  • Monolith vs microservices Simplicity vs independent scaling
  • Sync call vs async event Simple flow vs resilience

Quick maths

  • 1 day ~86,400 s (use 10^5)
  • 1M requests/day ~12 req/s average
  • Peak ~3 to 5x average
  • 1 KB x 1B rows ~1 TB
  • 2^10 / 2^20 / 2^30 / 2^40 Thousand, million, billion, trillion
  • base62, 7 chars ~3.5 trillion ids
  • 1 Gbps ~125 MB/s
Donate