Senior system design interviews often move from boxes and arrows to the hard part: what happens when machines disagree, clocks drift and a transaction spans more than one service. This fifth set covers the distributed systems ideas behind that discussion, including consensus with Raft, logical clocks, two-phase commit, safe distributed locks and patterns such as the transactional outbox and event sourcing.
How to practise: read each question and tap the option you think is correct. You will see right away whether you got it, along with a short explanation, and your score is tracked at the bottom of the screen. This set has 15 questions.
Topics covered in this set
- Raft leader election, majorities and committed entries
- Why clusters use an odd number of nodes
- Lamport clocks, vector clocks and clock skew
- Two-phase commit and why it blocks
- Leases, fencing tokens and the outbox pattern
- Write-ahead logs, Bloom filters, gossip and event sourcing
System Design MCQs with answers and explanations
Q1. A Raft cluster has 5 nodes. How many nodes can fail while the cluster can still elect a leader and accept writes?
a) 1
b) 2
c) 3
d) 4
Q2. Why do etcd, ZooKeeper and Consul clusters usually have 3 or 5 nodes instead of 4?
a) Even numbers are not allowed by the software
b) 4 nodes need more disk space
c) A 4-node cluster needs 3 votes for a majority and so still tolerates only 1 failure, the same as 3 nodes, while adding more replication cost
d) 4 nodes cannot elect a leader
Q3. In Raft, when does a follower start an election?
a) When it has not heard a heartbeat from a leader before its randomized election timeout runs out
b) Every 10 seconds no matter what
c) When a client asks it to
d) Only when an administrator runs a command
Q4. When is a log entry considered committed in Raft?
a) As soon as the leader writes it to its own disk
b) When every node in the cluster has stored it
c) When a client reads it
d) When the leader of the current term has replicated it to a majority of the servers
Q5. With Lamport clocks, if event a happened before event b, then L(a) < L(b). What about the reverse?
a) If L(a) < L(b), a definitely happened before b
b) If L(a) < L(b), we cannot conclude that a happened before b, because the events may be concurrent
c) Lamport clocks never compare events
d) L(a) is always equal to L(b)
Q6. What can vector clocks detect that Lamport clocks cannot?
a) The exact wall-clock time of an event
b) The network latency between nodes
c) That two events are concurrent, when neither vector is less than or equal to the other
d) Which node has the most CPU
Q7. A database resolves conflicts with last-write-wins using each server's wall-clock time. What is the main risk?
a) Clock skew between servers can make an older write look newer, so a real newer write is silently lost
b) Writes become too slow
c) Reads stop working
d) It needs a leader for every key
Q8. In two-phase commit, the coordinator crashes after all participants voted yes in the prepare phase but before it sent the decision. What happens to the participants?
a) They commit on their own after a timeout
b) They abort on their own after a timeout
c) They elect a new coordinator automatically using Raft
d) They stay blocked, holding locks, until the coordinator recovers and tells them the outcome
Q9. What are the two phases of two-phase commit, in order?
a) Prepare (each participant votes yes or no), then commit or abort (the coordinator sends the decision)
b) Lock, then unlock
c) Read, then write
d) Elect, then replicate
Q10. A service holds a distributed lock with a lease. It pauses for a long garbage collection, the lease expires and another service gets the lock. Why should the storage system check a fencing token on every write?
a) To make the lock faster
b) To compress the data
c) So that writes from the old lock holder, which carry a smaller token number, are rejected
d) To encrypt the lock
Q11. An order service must save an order to its database and also publish an OrderCreated event to Kafka. What does the transactional outbox pattern do?
a) Writes to Kafka first and the database later
b) Saves the order and an event row in an outbox table in the same local database transaction, and a separate relay publishes the outbox rows to Kafka
c) Uses two-phase commit between the database and Kafka
d) Publishes the event only when a user asks for it
Q12. Why do databases write changes to a write-ahead log (WAL) before changing the data files?
a) So that after a crash, the database can replay the log and recover committed transactions that were not yet written to the data files
b) To make reads faster
c) To save disk space
d) To avoid using indexes
Q13. A Bloom filter says a username is not in the set. What can you conclude?
a) The username might still be in the set
b) The username is definitely in the set
c) The filter is broken
d) The username is definitely not in the set
Q14. What is a gossip protocol mainly used for in systems such as Cassandra?
a) Sharing cluster membership and failure information, with each node regularly exchanging state with a few random peers so updates spread through the cluster
b) Encrypting traffic between nodes
c) Choosing the primary key of tables
d) Load balancing HTTP requests
Q15. What does event sourcing mean?
a) Reading events from a calendar
b) Logging only errors
c) Storing every change to an entity as an append-only sequence of events, and rebuilding the current state by replaying them
d) Sending emails when data changes
Quick revision notes
- A cluster of 2f+1 nodes tolerates f failures; use 3 or 5 nodes, not 4.
- Raft: randomized election timeouts; an entry is committed once the current leader replicates it to a majority.
- Lamport clocks respect causality one way; vector clocks detect concurrency; wall-clock last-write-wins can lose data.
- 2PC = prepare then commit/abort; it blocks if the coordinator dies after yes votes. Use fencing tokens with leased locks.
- Outbox pattern avoids dual writes; WAL gives crash recovery; Bloom filters have no false negatives; gossip spreads membership.
Frequently asked questions
Do I need to know Raft or Paxos in detail for interviews?
Usually not every step. You should know why a majority is needed, how a leader is elected, what happens when the leader fails and how many failures a cluster can survive. Deep protocol details are asked mainly for infrastructure and database roles.
When should I use two-phase commit and when a saga?
2PC gives atomic commits but blocks and couples services tightly, so it fits inside one database system or a small trusted set of resources. Across microservices, sagas with compensating actions and the outbox pattern are more common.
Is exactly-once delivery possible?
End to end, systems normally use at-least-once delivery plus idempotent processing or deduplication. Some tools, such as Kafka transactions, offer exactly-once processing within their own boundaries.
Comments
Post a Comment