Question 1

What does CAP actually trade off?

Accepted Answer

Under partition (P, network split), you choose between consistency (C — all reads see the latest write) and availability (A — every request returns a response). Partition is unavoidable in real networks, so CAP is really C-vs-A under partition. PACELC adds: even without partition, you trade consistency vs latency.

Question 2

What is the difference between linearizability and serializability?

Accepted Answer

Linearizability is a property of single operations: every read sees the most recent write in real time. Serializability is a property of transactions: the result is equivalent to some serial order. They're orthogonal — Spanner is both; SI is serializable but not linearizable; eventual consistency is neither.

Question 3

What is snapshot isolation, and how does it differ from serializable?

Accepted Answer

Snapshot isolation: each transaction reads from a fixed snapshot taken at start; writes are validated for write-write conflicts at commit. Prevents dirty reads, non-repeatable reads, lost updates. Permits write skew — two concurrent transactions can both pass their checks and produce a state no serial order could produce. Postgres' Repeatable Read is SI; Serializable adds rw-conflict detection (SSI).

Question 4

What does FLP impossibility prove?

Accepted Answer

In an asynchronous network (no upper bound on message delay), no deterministic algorithm can guarantee consensus in the presence of even one crash failure. Practical consensus protocols (Paxos, Raft) escape this by accepting weaker liveness — they're safe always, live during periods of partial synchrony.

Question 5

Why does Paxos need 2f+1 acceptors to tolerate f failures?

Accepted Answer

Quorum intersection. Any two majority quorums of 2f+1 nodes overlap in at least f+1 nodes. With at most f Byzantine-faulty or crashed, the overlap contains at least one honest node. That honest overlap carries information between phases and guarantees no two values can be chosen.

Question 6

How does Raft simplify consensus compared to Paxos?

Accepted Answer

Raft factors the consensus problem into three subproblems: leader election (only one node proposes), log replication (followers replicate the leader's log), and safety (a node can't be elected if it's missing committed entries). Multi-Paxos has the same machinery but doesn't describe it as cleanly.

Question 7

What does Byzantine fault tolerance require beyond crash tolerance?

Accepted Answer

For Byzantine failures (nodes that can lie, not just crash), you need 3f+1 nodes to tolerate f. The 2f+1 quorum geometry that works for crashes breaks under malicious behaviour because a faulty node can give different answers to different observers.

Question 8

What are Lamport timestamps for?

Accepted Answer

Logical clocks that capture happens-before relationships. Each event gets a counter; when a message is sent, its timestamp is stamped on it; the receiver bumps its counter to max(local, received) + 1. Gives a partial order. Can't detect concurrent events — if e1 || e2, Lamport timestamps don't distinguish from a sequential order.

Question 9

How are vector clocks different from Lamport clocks?

Accepted Answer

Vector clocks carry a counter per process, not one global counter. Comparing two vector clocks tells you exactly whether one happens-before the other, or whether they're concurrent. Cost: N counters per timestamp where N is process count. Dynamo uses them; modern systems often use hybrid logical clocks (HLC) instead.

Question 10

What does TrueTime guarantee that Lamport clocks do not?

Accepted Answer

TrueTime returns an interval [earliest, latest] bounding actual physical time. Commit-wait protocol: a transaction picks a commit timestamp s ≥ TT.now().latest, then waits until TT.now().earliest > s before releasing locks. Guarantees external consistency — real-time order is preserved across the global system.

Question 11

What property defines a CRDT?

Accepted Answer

A type whose merge operation is commutative, associative, and idempotent. Two replicas can apply updates in any order, with arbitrary delays, and converge to the same state — without coordination. Examples: G-Counter (grow-only), PN-Counter, OR-Set, LWW-Register, RGA (sequence).

Question 12

What is the difference between state-based and operation-based CRDTs?

Accepted Answer

State-based (CvRDT): replicas merge full state; merge function is the join of a semilattice. Needs no message ordering — just durability. Operation-based (CmRDT): replicas broadcast each operation; receivers apply them; needs causal delivery (e.g., via vector clocks). State-based is simpler to reason about; op-based has lower bandwidth per change.

Question 13

Why does Dynamo require R+W>N?

Accepted Answer

With N replicas, W = write quorum, R = read quorum, R+W>N guarantees that any read overlaps with any recent write in at least one replica — so the reader sees the latest version. Dynamo defaults to N=3, W=2, R=2 in many deployments, balancing latency against consistency.

Question 14

What is read-your-writes consistency?

Accepted Answer

After a client writes value V, all subsequent reads by THAT client must return V or a later value. Easier than full linearizability — only one client's view must be consistent. Implementations: route the client to the same replica, or include a write-sequence token on read requests.

Question 15

What is the trade-off in leader-based replication?

Accepted Answer

Single-leader systems are simple and correct but limited by the leader's write throughput, and write-availability depends on rapid failover. Multi-leader systems scale writes but introduce conflict resolution. Leaderless (Dynamo) gives availability at the cost of weaker consistency guarantees.

Question 16

Why does 2PC block?

Accepted Answer

If the coordinator crashes after some participants have received commit but others have not, the rest are stuck — they voted yes, hold locks, can't unilaterally decide. They have to wait for the coordinator to recover or for manual intervention. This is what makes 2PC unsuitable for high-availability cross-service transactions.

Question 17

When should you reach for a saga instead of a distributed transaction?

Accepted Answer

Across services that you don't own atomically, or across services where holding locks during 2PC would dominate latency. Sagas decompose a transaction into local transactions plus compensations. The cost: no isolation — other transactions can see partial saga state.

Question 18

Why is exactly-once delivery a myth?

Accepted Answer

The sender can't tell whether a missing acknowledgement means the message was lost or the ack was lost. To guarantee delivery, retry; to avoid duplicates, the receiver dedupes. The only achievable contract is at-least-once delivery + idempotent processing — which together LOOK like exactly-once at the app layer.

Question 19

What is the outbox pattern?

Accepted Answer

When a local DB write needs to also publish an external message: write both the change AND a row in an `outbox` table inside the same local transaction. A separate worker drains the outbox and publishes externally. Bridges DB durability and external message delivery without 2PC.

Question 20

What problem does consistent hashing solve?

Accepted Answer

Adding or removing a node in a hash-based shard scheme normally re-maps every key. Consistent hashing maps keys onto a ring; each node owns an arc. Adding a node moves only K/N keys — the keys on the arc the new node takes over. Used in Dynamo, Cassandra, Maglev, Memcached clients.

Question 21

How does Maglev hashing differ from rendezvous hashing?

Accepted Answer

Rendezvous: for each key, hash key+server for every server; pick the highest hash. O(N) per lookup. Maglev: precompute a fixed-size lookup table (typically 65537 entries) once per backend set change. O(1) per lookup, ~1/N entries change when set changes. Maglev wins on performance; rendezvous wins on stability under heavy churn.

Question 22

What is a hot shard and how do you fix it?

Accepted Answer

When a single shard receives disproportionate traffic — usually because of a hot key (one popular user) or skewed access patterns. Fixes: re-shard by a derived key (key+random suffix), separate the hot key onto its own shard, or use a cache in front. The pre-emptive fix is to avoid shard keys that correlate with workload skew.

Question 23

Why does p99 at one server determine p50 at the user?

Accepted Answer

If a request fans out to N servers and the user sees the slowest, the probability that ALL servers are below their p99 is (0.99)^N. At N=100 that's 37%, so 63% of users see at least one p99-class response. p99 at one server is the user's p50.

Question 24

How do hedged requests reduce tail latency?

Accepted Answer

Send the same request to two replicas; use whichever responds first. If a hedge fires only after the original is slow (say, exceeds p95), the extra load is bounded but the user sees a much-faster tail. Standard technique in BigQuery, Spanner, gRPC.

Question 25

What is the retry storm problem?

Accepted Answer

Service A is slow, callers timeout, callers retry. The retries arrive at A faster than the original load. A gets slower. More timeouts, more retries. Death spiral. Mitigations: exponential backoff with jitter, retry budgets (cap retries to X% of original requests), circuit breakers that stop retrying when downstream is sick.

Question 26

What is a circuit breaker?

Accepted Answer

A wrapper around remote calls that tracks recent failures. Closed: calls pass through. After N failures in a window, breaker opens — short-circuits calls, returns errors immediately, no upstream load. After a cooldown, half-open — a few trial calls go through; if they succeed, close; if not, re-open. Implemented by Hystrix, Resilience4j, every modern service mesh.

Question 27

What does the phi-accrual failure detector improve on?

Accepted Answer

Binary timeout-based detection: 'no heartbeat for T seconds → dead'. Phi-accrual produces a continuous suspicion level that adapts to the observed heartbeat-interval distribution. Same effective timeout for a stable network, but it stops generating false suspicions when the network's stddev is high.

Question 28

How does SWIM achieve O(log N) failure detection?

Accepted Answer

Each node pings 1 random peer per round. If no ack, ask K other peers to ping it indirectly. Failure is then gossipped through the cluster. Direct + indirect pings keep false-positive rate low; gossip propagation is logarithmic in cluster size. O(N) total messages per round regardless of N. HashiCorp Serf is the textbook implementation.

Question 29

How does Raft elect a leader?

Accepted Answer

On election timeout, a follower becomes candidate, increments term, votes for itself, requests votes from peers. Peers vote at most once per term, only for candidates with at-least-as-recent logs. Candidate with majority votes becomes leader. Election timeouts are randomised (150–300ms) to reduce split votes.

Question 30

Why do distributed locks need fencing tokens?

Accepted Answer

Imagine client A acquires a lock, GCs for 30 seconds, lock expires, client B acquires it, then A resumes and writes — corruption. Fencing token: lock service issues a monotonic token with each acquisition. Storage rejects writes with stale tokens. The token, not the lock, gates writes.

Question 31

What is the difference between B-tree and LSM-tree write amplification?

Accepted Answer

B-tree: each insert may rewrite a leaf page; high random-write cost, low read amp. LSM-tree: each insert is an append, but background compaction rewrites records O(log N) times as they cascade through levels. LSM trades write-amp for sequential writes. Read amp on LSM is higher (must check multiple levels), mitigated by bloom filters.

Question 32

Why does write-ahead logging guarantee durability?

Accepted Answer

Before modifying any database page, write the change to a sequential log on stable storage and fsync. On crash, replay the log from the last checkpoint forward to recover. The log is sequential (fast); pages can be written lazily. Without WAL, in-place updates either corrupt on crash or require synchronous page writes (slow).

Question 33

What does MVCC give you that locking doesn't?

Accepted Answer

Multi-version concurrency control keeps multiple versions of each row; readers see a snapshot, writers create new versions. Readers don't block writers, writers don't block readers. Long analytics queries can coexist with OLTP without lock contention. Cost: version chains have to be vacuumed.

Question 34

How does epoll achieve O(1) event multiplexing?

Accepted Answer

Unlike select/poll which scan the full FD set per call, epoll has a kernel-side data structure: register FDs once, the kernel maintains a ready list as events fire. epoll_wait returns just the ready FDs. Scales to millions of connections per box. The breakthrough that enabled C10K and beyond.

Question 35

Why is io_uring faster than epoll for high-throughput I/O?

Accepted Answer

epoll requires a syscall per I/O event (read/recv). io_uring uses shared-memory ring buffers between user and kernel — submit thousands of operations and reap completions with one syscall pair. Cuts syscall overhead 10× for I/O-heavy workloads. ScyllaDB, recent nginx, recent libuv all use it.

Question 36

What does CFS optimise for?

Accepted Answer

Completely Fair Scheduler — each runnable thread gets approximately equal CPU share over time, weighted by nice value. Tracks 'virtual runtime' per thread; always runs the thread with smallest vruntime. Default Linux scheduler since 2007; EEVDF (6.6+) is a refinement with better latency behaviour for interactive workloads.

Question 37

Why does TCP have head-of-line blocking and QUIC does not?

Accepted Answer

TCP is a single byte stream. If one segment is lost, every byte after it must wait for retransmission, even logically-independent data. QUIC has multiple independent streams over a single connection — loss on stream A doesn't block stream B. This is the killer feature that motivated HTTP/3.

Question 38

What does TLS 1.3 strip compared to 1.2?

Accepted Answer

All RSA key exchange (PFS only). All static-key ciphersuites. CBC modes. SHA-1. Renegotiation. Compression. Cuts the handshake from 2 RTT to 1 RTT (0 RTT for resumption). Modern AEAD ciphers (AES-GCM, ChaCha20-Poly1305) only. The cleaner protocol came at the cost of breaking some middleboxes that hard-coded TLS 1.2 assumptions.

Question 39

What is the difference between L4 and L7 load balancing?

Accepted Answer

L4 (transport): forwards TCP/UDP packets without parsing payload. ~10M pps per core on XDP. L7 (application): terminates TLS, parses HTTP, routes on path/host/headers. ~100k rps per core. Typical stack: L4 at the edge for DDoS absorption, L7 per region for routing.

Question 40

What does Little's Law say?

Accepted Answer

L = λ × W. The average number in a system (L) equals the average arrival rate (λ) times the average time spent (W). At p99 latency 50 ms and 2000 rps, you have on average 100 concurrent requests. Useful for capacity planning: if W blows up, L blows up; if L is bounded (thread pool size), arrivals beyond a rate get queued.

Question 41

When is read-through caching better than write-through?

Accepted Answer

Read-through: cache misses fetch from origin, then cache. Write-through: every write updates both cache and origin. Read-through is better when reads dominate writes (typical); write-through guarantees cache freshness at the cost of write amplification. Cache-aside (app-managed) is more common than either.

Question 42

When is CP a better choice than AP?

Accepted Answer

When the cost of returning stale or wrong data exceeds the cost of unavailability — financial transactions, inventory, identity. ZooKeeper, etcd, Consul lean CP. AP makes sense when serving stale data is acceptable — DNS, CDN edge caches, social-feed timelines.

Question 43

What is the difference between availability and durability?

Accepted Answer

Availability: probability that a read or write succeeds at request time. Durability: probability that data committed in the past is still present. Typical cloud: 11 nines durability (S3), 4 nines availability (regional storage). Backups raise durability; replicas raise availability.

Question 44

What does Kubernetes guarantee about pod placement?

Accepted Answer

The scheduler binds a pod to a node based on resource requests, affinity rules, and constraints. Once bound, the pod runs there until removed; it isn't live-migrated. Reschedule happens only on pod restart (e.g., after a node failure). For higher availability, use Deployments + PodDisruptionBudgets, not migration.

Question 45

How does cgroup v2 differ from v1?

Accepted Answer

v1 had a separate hierarchy per controller (cpu, memory, io). v2 has a unified hierarchy — every cgroup has all controllers. Simpler model, better resource accounting, supports the IO controller properly. Required for many modern Kubernetes features (memory.high, swap controls). Major distros default to v2 since 2020.

Question 46

What does the Chandy-Lamport algorithm capture?

Accepted Answer

A consistent global snapshot of a distributed system — every process's local state plus every channel's in-flight messages — without stopping the system. Marker messages flow through channels; each process records its state when it sees a marker, then forwards markers downstream. Flink checkpoints use a variant.

Question 47

Why does PBFT need 3f+1 replicas?

Accepted Answer

Same quorum-intersection argument as crash-tolerant consensus but with Byzantine faults: a faulty node can give different answers to different observers, so the safe overlap must contain at least one honest node guaranteed. With n=3f+1, any two 2f+1 quorums overlap in at least f+1, of which one is honest.

Question 48

What problem does Calvin solve differently from Spanner?

Accepted Answer

Spanner uses 2PC over Paxos with TrueTime for cross-shard transactions; commit latency includes the slowest replica's roundtrip. Calvin globally orders all transactions through a Paxos-replicated sequencer before they execute, so execution is deterministic and needs no distributed locking. Trade-off: transactions must declare their read/write set in advance.

Question 49

What pattern unifies Helland's 2009 essay's advice?

Accepted Answer

All of distributed systems is about deciding which guarantees to give up and which to engineer around. Idempotency replaces exactly-once; sagas replace 2PC; eventual consistency replaces linearizability; out-of-band recovery replaces fail-safe writes. Acknowledge the limits, design around them.

Question 50

What is the relationship between Lamport clocks and HLC?

Accepted Answer

HLC (Hybrid Logical Clocks) combine wall-clock time and Lamport-style counters. Each timestamp = (max(wall_clock, last_seen) << 16) | logical_counter. Resyncs with NTP automatically when wall_clock jumps; preserves causal ordering. CockroachDB and YugabyteDB use HLC instead of TrueTime since they can't deploy GPS+atomic-clock hardware.

Question 51

What is the difference between strong eventual consistency and eventual consistency?

Accepted Answer

Eventual: replicas converge if updates stop. Strong eventual: replicas that have seen the same set of updates have the same state, regardless of the order. The latter is what CRDTs guarantee; the former is what classical eventual-consistency systems (Dynamo without CRDTs) provide.

Question 52

What is the difference between OLTP and OLAP workloads?

Accepted Answer

OLTP: many small transactions, low latency per query, row-oriented storage. Banking, e-commerce, social media. OLAP: few large scans + aggregations over the whole dataset, column-oriented storage, dimensional schemas. Reporting, BI, ML feature pipelines. Same SQL syntax; entirely different engines underneath.

Question 53

When should you reach for a NoSQL store over a relational database?

Accepted Answer

When the data shape doesn't fit into joinable rows (JSON documents, time-series points, graphs), when you need horizontal write scale beyond a single primary, or when the operational model (managed Dynamo / Bigtable) buys more than schemaless flexibility costs. Default to Postgres until one of those three justifies leaving.

Question 54

What is the write amplification of an LSM-tree and why does it matter?

Accepted Answer

Each record is rewritten O(log_T N) times as it cascades through compaction levels (T is the level size ratio, usually 10). For a 1 TB dataset with T=10, write amp is ~7×. Matters because SSD endurance and write throughput are budgeted in bytes per second — write amp eats both.

Question 55

What does vacuum do in Postgres?

Accepted Answer

Postgres uses MVCC — updates and deletes leave dead row versions. Vacuum reclaims that space by marking dead tuples as free for reuse. Without it, the table bloats indefinitely. Autovacuum runs in the background; manual VACUUM FULL rewrites the table (with a heavy lock). Long transactions block vacuum because the snapshot they hold counts dead tuples as still-needed.

Question 56

What is the difference between a clustered and a non-clustered index?

Accepted Answer

Clustered: the table is physically ordered by the index key — one per table. MySQL InnoDB always uses the PK as the clustered index; secondary indexes store the PK and require a second lookup. Non-clustered (Postgres B-tree): the index points to row IDs (TIDs); the table heap is unordered. Clustered indexes win on range scans of the key.

Question 57

What problem does a covering index solve?

Accepted Answer

If an index includes every column the query needs, the database can answer the query from the index alone — no heap lookup. Reduces I/O dramatically for hot queries. Cost: the index is bigger; writes update more bytes. Use sparingly, only for queries that dominate your workload.

Question 58

Why do dimensional models (star schemas) win for analytics?

Accepted Answer

A fact table joins to N small dimension tables — query planners produce trivially good plans. Adding a new analytical question is just adding a join. Compare to a deeply normalised OLTP schema where the same question requires 8 joins through bridge tables. Star schemas trade duplicated data for query simplicity at the cost of write complexity.

Question 59

What does ANALYZE do, and when does it matter?

Accepted Answer

Updates the planner's statistics about table sizes, value distributions, and correlations. The planner uses these to pick join order and index strategies. Stale stats are why 'the query was fast yesterday' — after a big data import or a column distribution shift, run ANALYZE. Postgres autoanalyze is enabled by default but lags on bursty changes.

Question 60

How does the TCP three-way handshake actually work?

Accepted Answer

Client SYN with initial sequence number X. Server SYN-ACK with its own ISN Y and ack=X+1. Client ACK with ack=Y+1. After 3 messages and 1 RTT, both sides know each other's ISN and the connection is established. The ISNs exist to detect old packets from previous connections.

Question 61

What is the practical difference between HTTP/1.1, HTTP/2, and HTTP/3?

Accepted Answer

HTTP/1.1: one request per TCP connection (pipelining never worked); browsers open 6 connections per origin. HTTP/2: multiplexes many requests over one TCP connection; suffers from TCP head-of-line blocking on packet loss. HTTP/3: same multiplexing, but over QUIC (UDP-based) — independent streams avoid HoL blocking; fuses TCP + TLS into 1 RTT.

Question 62

Why do CDNs use anycast routing?

Accepted Answer

The same IP is advertised from many points of presence via BGP. ISPs route to the topologically-nearest one. Result: every user reaches a nearby PoP without any DNS-based geo magic. Failure handling: when a PoP dies, BGP withdraws the route and traffic shifts to the next-nearest. The whole system is self-healing.

Question 63

What does TCP slow start actually do?

Accepted Answer

Start with cwnd of 10 MSS (modern Linux). Each ACK roughly doubles cwnd for one RTT. Continues until cwnd hits ssthresh, then linear (congestion avoidance). The word 'slow' in slow-start is historical — at 1 byte per RTT in the original, it really was slow. Today it's the fastest legitimate ramp-up.

Question 64

When would you pick UDP over TCP?

Accepted Answer

When the application can tolerate loss or implement its own reliability (DNS, RTP for media, QUIC's underlying transport), when you need multicast/broadcast, or when you need very small packet overhead. UDP doesn't try to be reliable, ordered, or congestion-controlled — those become application concerns.

Interview flashcards.

How to study with flashcards

A four-pass study cadence

Topic coverage

What the cards do not cover

Frequently asked questions

Related on Semicolony