System Design Fundamentals of System Design Syllabus

How do you estimate storage needed per year for a stream of writes?

$$\text{Storage/year} = \text{writes per day} \times \text{bytes per write} \times 365$$ Then multiply by a replication factor if data is replicated. E.g., $1$M writes/day $\times 1\,\text{KB} \times 365 \approx 365\,\text{GB/year}$ before replication.

State the CAP theorem and name its three properties.

CAP theorem: a distributed data store can simultaneously guarantee at most two of three properties — Consistency (every read sees the latest write), Availability (every request gets a non-error response), and Partition tolerance (system keeps working despite network partitions). Since network partitions are unavoidable, real systems must trade off between C and A during a partition.

During a network partition, what choice does CAP force, and what are the two resulting system types?

When a partition occurs, a system must choose between consistency and availability. A CP system rejects/blocks requests that can't be made consistent (sacrificing availability) to avoid stale/conflicting data. An AP system keeps serving requests on both sides (sacrificing consistency), accepting possibly stale data and reconciling later.

Give examples of CP versus AP systems.

CP (favor consistency during partitions): traditional RDBMS with synchronous replication, HBase, MongoDB (default), ZooKeeper, etcd. AP (favor availability during partitions): Cassandra, DynamoDB, Riak, CouchDB. The classification reflects behavior under partition, not absolute categorization.

State the PACELC theorem and what it adds beyond CAP.

PACELC extends CAP: if there is a Partition (P), trade off between Availability (A) and Consistency (C); Else (E), when running normally, trade off between Latency (L) and Consistency (C). It captures that even without partitions, systems trade latency against consistency — something CAP ignores.

Classify Dynamo-style and traditional systems using PACELC notation.

PACELC labels a system by both trade-offs. Cassandra/DynamoDB are typically PA/EL (favor availability under partition, latency otherwise). A fully consistent system like a traditional RDBMS or MongoDB is PC/EC (favor consistency in both cases). Some are PA/EC or PC/EL depending on tuning.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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}$.

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).

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.

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.

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).

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.