🌍 System Design · flashcards

System Design Fundamentals of System Design Flashcards

50 question-and-answer cards covering Fundamentals of System Design as it is examined in System Design. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.

50Cards in deck
24Free preview
19Syllabus topics
~348Chars per answer
FreePrice

24 sample cards from the Fundamentals of System Design deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

  1. Define strong consistency and its main cost.

    Strong consistency guarantees that after a write completes, all subsequent reads (from any node) return that write or a newer one — the system behaves as if there is a single up-to-date copy (linearizability). Its cost is higher latency and reduced availability, because writes must be coordinated/replicated synchronously across nodes before acknowledging.

  2. What is linearizability?

    Linearizability is the strongest single-object consistency model: every operation appears to take effect atomically at some instant between its invocation and completion, and once a read returns a value, all later reads return that value or a newer one. It provides a real-time ordering guarantee, making the system appear as a single, up-to-date copy of the data.

  3. Define eventual consistency and when it is appropriate.

    Eventual consistency guarantees that, if no new updates are made, all replicas will eventually converge to the same value — but reads may temporarily return stale data. It suits high-availability, high-throughput systems where temporary staleness is acceptable (e.g., DNS, social media feeds, shopping-cart counts) and offers low latency and partition tolerance.

  4. What is causal consistency and what does it preserve?

    Causal consistency ensures that operations causally related (one could have influenced another, per the happens-before relation) are seen by all processes in the same order; concurrent (unrelated) operations may be seen in different orders. It preserves cause-and-effect ordering — e.g., a reply is never seen before the message it answers — while being weaker (and more available) than strong consistency.

  5. What is read-your-writes consistency?

    Read-your-writes (read-your-own-writes) consistency guarantees that after a process writes a value, its own subsequent reads always reflect that write (never an older value). It is a session/client-centric guarantee that prevents a user from, e.g., updating their profile and then seeing the old version, even in an otherwise eventually consistent system.

  6. Name common client-centric (session) consistency guarantees.

    Read-your-writes (see your own updates), monotonic reads (never see data go backward in time), monotonic writes (your writes are applied in order), and writes-follow-reads/causal (a write after a read is ordered after the value read). These provide intuitive per-session guarantees on top of eventually consistent stores.

  7. Explain quorum-based consistency and the formula for strong consistency.

    With $N$ replicas, a read must contact $R$ replicas and a write must be acknowledged by $W$ replicas. Strong consistency is guaranteed when reads and writes overlap: $$R + W > N$$ ensuring any read quorum intersects the latest write quorum. Also requiring $W > N/2$ prevents conflicting concurrent writes.

  8. In quorum systems, how do you tune $R$ and $W$ for read-heavy versus write-heavy workloads?

    For fast reads (read-heavy): set $R$ small and $W$ large (e.g., $W = N$, $R = 1$) so reads are cheap while still satisfying $R+W>N$. For fast writes (write-heavy): set $W$ small and $R$ large (e.g., $W=1$, $R=N$). Lowering both below the $R+W>N$ threshold sacrifices strong consistency for lower latency/higher availability.

  9. Compare TCP and UDP across reliability, ordering, connection, and use cases.

    TCP is connection-oriented, reliable (acknowledgements + retransmission), ordered, flow- and congestion-controlled, with higher overhead — used for web, email, file transfer. UDP is connectionless, unreliable (no ACK/retransmit), unordered, with minimal overhead and lower latency — used for streaming, VoIP, gaming, and DNS queries.

  10. Describe the TCP three-way handshake.

    To establish a connection: (1) client sends SYN with an initial sequence number; (2) server replies SYN-ACK (its own SYN plus ACK of the client's); (3) client sends ACK. After these three messages both sides have synchronized sequence numbers and the connection is established. Sequence: $\text{SYN} \to \text{SYN{-}ACK} \to \text{ACK}$.

  11. Where do TCP, UDP, and IP sit in the TCP/IP model, and what does each layer do?

    IP is at the Internet (network) layer: logical addressing and routing of packets between hosts (best-effort, connectionless). TCP and UDP are at the Transport layer: process-to-process delivery via ports — TCP adds reliability/ordering, UDP is minimal. Above them is the Application layer (HTTP, DNS, etc.); below is the Link layer (Ethernet, Wi-Fi).

  12. What is the difference between HTTP and HTTPS?

    HTTP is a stateless, text-based application-layer request/response protocol, transmitted in plaintext (default port 80). HTTPS is HTTP layered over TLS/SSL (default port 443), providing encryption (confidentiality), integrity, and server authentication via certificates. HTTPS prevents eavesdropping and tampering; HTTP does not.

  13. List the main HTTP methods and whether they are idempotent/safe.

    GET (safe, idempotent — retrieve), HEAD (safe, idempotent — headers only), PUT (idempotent — replace), DELETE (idempotent — remove), POST (not idempotent — create/submit), PATCH (not necessarily idempotent — partial update), OPTIONS (safe). Safe = no state change; idempotent = repeating has the same effect as once.

  14. Summarize the HTTP status code classes.

    1xx Informational; 2xx Success (e.g., 200 OK, 201 Created, 204 No Content); 3xx Redirection (301 Moved Permanently, 302 Found, 304 Not Modified); 4xx Client Error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests); 5xx Server Error (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout).

  15. What key improvements did HTTP/2 introduce over HTTP/1.1?

    HTTP/2 added: multiplexing (many concurrent streams over one TCP connection, eliminating head-of-line blocking at the HTTP layer), binary framing (vs text), header compression (HPACK), stream prioritization, and server push. It reduces latency and connection overhead while remaining semantically compatible with HTTP/1.1.

  16. What problem does HTTP/2 still have, and how does HTTP/3 solve it?

    HTTP/2 multiplexes streams over a single TCP connection, so a lost TCP packet stalls all streams (TCP head-of-line blocking). HTTP/3 runs over QUIC (built on UDP), which provides independent streams so packet loss affects only one stream. QUIC also integrates TLS 1.3 for faster (often 0-RTT) connection setup and supports connection migration across network changes.

  17. What is QUIC and why does it use UDP?

    QUIC is a transport protocol (the basis of HTTP/3) implemented on top of UDP in user space. It uses UDP to avoid TCP's kernel-level head-of-line blocking and to enable rapid iteration/deployment, while itself providing reliability, congestion control, per-stream ordering, built-in TLS 1.3 encryption, faster handshakes (0-/1-RTT), and connection migration via connection IDs.

  18. What is DNS and what problem does it solve?

    DNS (Domain Name System) is the distributed, hierarchical naming system that translates human-readable domain names (e.g., example.com) into IP addresses (e.g., 93.184.216.34) that machines use to route traffic. It acts as the internet's phone book, decoupling stable names from changeable IPs.

  19. Describe the steps of recursive DNS resolution.

    On a cache miss, a recursive resolver queries: (1) a root nameserver, which returns the TLD server for the extension (e.g., .com); (2) the TLD nameserver, which returns the authoritative nameserver for the domain; (3) the authoritative nameserver, which returns the actual record (e.g., A record with the IP). The resolver caches results (per TTL) and returns the IP to the client.

  20. Explain the DNS server hierarchy: resolver, root, TLD, authoritative.

    Recursive resolver: queries on the client's behalf and caches answers. Root nameservers: top of the hierarchy; direct queries to the correct TLD servers. TLD nameservers: manage a top-level domain (.com, .org, .net) and point to authoritative servers. Authoritative nameservers: hold the actual DNS records for a domain and give the definitive answer.

  21. Define common DNS record types: A, AAAA, CNAME, MX, NS, TXT.

    A: maps a name to an IPv4 address. AAAA: maps a name to an IPv6 address. CNAME: aliases one name to another canonical name. MX: mail exchange server for the domain (with priority). NS: delegates a zone to authoritative nameservers. TXT: arbitrary text, used for verification and email auth (SPF, DKIM, DMARC).

  22. What is DNS TTL and how does caching affect propagation?

    TTL (Time To Live) is the number of seconds a DNS record may be cached by resolvers before it must be re-fetched. High TTL improves performance and reduces lookups but slows propagation of changes; low TTL speeds propagation of updates (e.g., for failover) at the cost of more frequent queries. 'DNS propagation delay' after a change is bounded by the old record's TTL.

  23. How can DNS be used for load balancing and high availability?

    DNS can return multiple A records (round-robin) to distribute clients across servers, use geo-/latency-based routing to send users to the nearest region, and support failover by lowering TTL and updating records to healthy endpoints. Weighted records enable canary/gradual rollouts. Limitations include client caching and coarse-grained control compared to L4/L7 load balancers.

  24. Compare strong versus eventual consistency across guarantees, latency, and availability.

    Strong consistency: reads always see the latest write (single-copy illusion), but higher write latency and lower availability under partitions (tends toward CP). Eventual consistency: reads may be stale but replicas converge over time, giving lower latency and higher availability/partition tolerance (tends toward AP). The choice trades data freshness against performance and uptime.

What this deck covers

The Fundamentals of System Design deck follows the System Design Fundamentals of System Design syllabus — 5 chapters and 19 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 10.0 cards per chapter.

Answers are written to be recallable, not just readable — averaging about 348 characters, which is long enough to carry the reasoning and short enough to say out loud.

A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.

Fundamentals of System Design flashcards FAQ

How many Fundamentals of System Design flashcards are in this System Design deck?

50 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.

Are these System Design flashcards free?

Yes. The preview here is free to read with no signup, and the full 50-card deck is free inside the Examius app.

What do the Fundamentals of System Design cards cover?

They follow the System Design Fundamentals of System Design syllabus — 5 chapters and 19 topics — so the questions track what is actually examinable.

How should I use these flashcards?

Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.