We use analytics and advertising cookies to understand how the site is used and whether our ads on Facebook and Instagram work. They are set only if you accept. See our Privacy Policy for details.
Distributed systems questions sit inside system design rounds and decide senior levels: what happens to your design when a node, a network link or a clock fails. Interviewers ask about replication lag, quorum reads, leader election, transactions that span services, and retries that must not double-charge anyone.
Each question below is a scenario with four plausible answers and an explanation.
Answer a real System Design interview question before you browse the Distributed Systems list. No signup needed.
One order event must trigger inventory, notification and analytics processing. Each consumer must receive every event independently and process at its own pace, and a slow consumer must not affect the others. What pattern should be used?
Practice in a session
10 questions from System Design, one after another, then your score and streak.
CAP and PACELC, consistency models, leader-follower, multi-leader and leaderless replication with quorums, partitioning and consistent hashing, consensus (Raft, Paxos) and leader election, distributed transactions (two-phase commit and sagas), idempotency and delivery semantics, clocks and ordering, failure detection, and circuit breakers and backpressure.
When a network partition separates nodes, a distributed system has to choose between consistency (every read sees the latest write) and availability (every request gets a response). It says nothing about the normal case; PACELC adds that, without a partition, you still trade latency against consistency.
Two-phase commit makes participants prepare, then commit together, which gives atomicity but holds locks and blocks if the coordinator fails. A saga runs a sequence of local transactions and undoes completed steps with compensating actions on failure, so it holds no global locks and fits services with their own databases, at the cost of eventual consistency and compensation logic.
Delivery over a network is at-least-once or at-most-once. Exactly-once effects come from at-least-once delivery plus idempotent processing - an idempotency key, a dedup table or a conditional write - or from committing the output and the consumer offset in one transaction.