Top 30 Distributed Systems Interview Questions and Answers
30 multiple-choice questions on Distributed Systems, drawn from 30 bites out of the 31 tagged Distributed Systems on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
Across three microservices handling one request, what value is identical on every span, and what value distinguishes each operation within that request?
Show the answer
Answer: a · Trace ID is shared; span ID distinguishes each operation
The trace ID is generated once and carried by every span to group them, while each operation gets its own span ID. Sharing span IDs or minting new trace IDs per hop would break correlation entirely.
Question 2 of 30
When implementing a timezone-safe offer countdown, which design prevents users from manipulating the expiry?
Show the answer
Answer: d · Let the server own the canonical UTC deadline, have the client sync via a server-time offset, and re-validate expiry at checkout.
This is the only option that keeps the canonical deadline on the server, uses a server-relative offset for display, and enforces expiry at checkout. Option A is tempting because localStorage seems like a simple way to persist state, but it allows trivial tampering with the deadline.
Read the full bite: How would you implement a timezone-safe, tamper-proof offer countdown?
Question 3 of 30
Two clients concurrently update the same object in a strongly consistent object store. What is the realistic outcome?
Show the answer
Answer: b · Last writer wins and one update is silently lost without coordination
Object stores replace whole objects with no built-in locking, so concurrent PUTs are last-writer-wins and an update is lost unless you use conditional writes. There is no automatic merge, lock, or reconciliation.
Question 4 of 30
When is choosing eventual consistency over strong consistency the better engineering decision?
Show the answer
Answer: d · When brief staleness is harmless and you want lower latency, cost, and higher availability
Eventual consistency trades momentary staleness for speed, lower cost, and availability, ideal for tolerant data like feed counts. Balance checks need strong consistency, making the first option wrong.
Read the full bite: Strong versus eventual consistency in NoSQL
Question 5 of 30
According to the CAP theorem, what is the actual decision a distributed system faces, and when does it apply?
Show the answer
Answer: d · During a network partition you must trade off between consistency and availability
Because partitions are inevitable, the binding choice arises only during a partition: stay consistent and reject requests, or stay available and serve stale data. The pick-two framing and dropping partition tolerance are common misreadings.
Question 6 of 30
Which feature is the clearest case where eventual consistency would be unacceptable and strong consistency is required?
Show the answer
Answer: c · Decrementing the remaining stock of a limited-edition item at checkout
Limited inventory must be strongly consistent or two buyers could purchase the same last unit. View counts, follower counts, and feeds tolerate brief staleness without causing real harm.
Read the full bite: What are eventual consistency and the BASE model?
Question 7 of 30
According to the CAP theorem, when is the consistency-versus-availability tradeoff actually forced on a distributed database?
Show the answer
Answer: c · Only during a network partition, when the system must choose consistency or availability
Partition tolerance is mandatory, so the real choice between consistency and availability only arises during a partition. Outside a partition a system can offer both, and Spanner does not beat CAP.
Question 8 of 30
What guarantee does a Saga provide that distinguishes it from a true multi-document ACID transaction?
Show the answer
Answer: b · It provides atomicity via compensating transactions but not isolation, so partial states can be observed
A Saga achieves all-or-nothing through compensations but cannot isolate intermediate steps, so partial results are visible. Locking all participants describes two-phase commit, and Sagas yield eventual, not instant strong, consistency.
Read the full bite: How do you keep consistency without multi-document transactions?
Question 9 of 30
When improving API p99 from 500ms to 200ms in a distributed system, which validation strategy best ensures real user benefit without hidden side effects?
Show the answer
Answer: a · Deploy fine-grained edge histograms, propagate trace context across hops, and watch error rates, throughput, and cost
The correct strategy uses histograms to accurately detect true tail shifts, trace context to pinpoint which backend hop inflates latency, and complementary metrics to guard against side effects. Option D is tempting because it artificially lowers the percentile, but it hides latency by converting slow requests into errors, which directly harms user experience.
Read the full bite: Monitor p99 improvement from 500ms to 200ms and side effects
Question 10 of 30
In an availability-first system facing partitions, which approach best prevents silently losing concurrent updates to the same data?
Show the answer
Answer: d · Merging divergent replicas with a conflict-free replicated data type that combines updates deterministically
A CRDT deterministically merges concurrent updates, so neither side's change is dropped. Last-write-wins silently discards one concurrent update, linearizability conflicts with staying available under partition, and disabling replication harms availability.
Read the full bite: What consistency do you sacrifice in an AP system?
Question 11 of 30
Why must user variant assignment remain fixed throughout an email A/B test rather than re-randomizing daily?
Show the answer
Answer: c · It prevents users from seeing both variants and polluting statistical independence.
Deterministic bucketing locks each user to a single variant, keeping observations independent for valid hypothesis testing, whereas re-randomization lets users flip groups and contaminates results. Mid-test traffic shifting introduces peeking bias, and exactly-once semantics is an event-tracking concern unrelated to bucketing.
Read the full bite: Architect email subject line A/B testing for a large user base
Question 12 of 30
A banking ledger refuses writes on a node it cannot safely coordinate during a network partition. How does this position it on the CAP trade-off?
Show the answer
Answer: d · It is a CP system sacrificing availability to preserve consistency during the partition
Refusing writes to avoid divergence trades availability for consistency, the defining behavior of a CP system under partition. Serving despite staleness would be AP, and CAP's trade-off cannot be escaped in a distributed system.
Question 13 of 30
A team moves from leader-follower to multi-leader replication across two regions. Which new problem must they now explicitly design for?
Show the answer
Answer: b · Concurrent conflicting writes to the same record
Multiple leaders accepting writes asynchronously means two regions can edit the same record concurrently, requiring conflict resolution. Stale read replicas also exist in plain leader-follower, so that is not the new problem multi-leader introduces.
Read the full bite: Leader-follower vs multi-leader replication
Question 14 of 30
Which feature is the WEAKEST candidate for eventual consistency and most likely needs strong consistency instead?
Show the answer
Answer: b · Decrementing limited inventory at checkout
Selling the same last unit twice due to a stale read causes real harm, so inventory decrement at checkout needs strong consistency. Like counts, follower numbers, and trending lists tolerate brief staleness without consequence.
Question 15 of 30
In a 3-replica shard using a write quorum of 2, when is it safe to confirm a write to the client?
Show the answer
Answer: d · After the WAL entry is durably persisted on at least two replicas
A write quorum of two means the entry must be durably persisted on two of three replicas before confirming, so it survives one node loss. Memory-only or routing-layer acks are not durable, and waiting for all three sacrifices availability unnecessarily.
Read the full bite: Durable write path in a sharded KV store
Question 16 of 30
A 5-node Raft cluster partitions into groups of 3 and 2. What happens on the 2-node side?
Show the answer
Answer: d · It cannot reach quorum, so it cannot elect a leader or commit writes
Raft requires a majority (3 of 5) to elect a leader and commit, so the 2-node minority cannot make progress, preventing split-brain. The 3-node majority side continues normally, so the cluster does not fully freeze.
Question 17 of 30
A shard is hot because writes use a sequential timestamp key. Which fix actually resolves the root cause rather than just buying time?
Show the answer
Answer: a · Change the partition key to a hash so writes spread evenly
A sequential key sends all new writes to one shard; hashing the key spreads writes across shards, fixing the cause. Read replicas and caching only help reads, and vertical scaling postpones the same write hot spot.
Question 18 of 30
In a minimal production-ready feature flag system, how should an application SDK typically check if a feature is enabled at runtime?
Show the answer
Answer: b · Evaluate the flag against a locally cached copy of definitions refreshed periodically from the control service.
The card emphasizes that the SDK must cache flag definitions locally and evaluate them instantly without a network round-trip on every check, falling back to cached values when the control service is unavailable. Option D is tempting because reaching out to the control service feels authoritative, but synchronous per-check requests introduce latency and a dangerous hard dependency.
Read the full bite: How would you implement a simple feature flag system?
Question 19 of 30
Which combination of strategies best addresses GPU resource contention when a platform team must support both long-running distributed training and low-latency model serving on the same A100 cluster?
Show the answer
Answer: a · Segmenting workloads by checkpointability and criticality, using PriorityClasses with preemption for training tiers, and reserving MIG slices for serving while keeping full GPUs for distributed training
The correct approach segments workloads by checkpointability and criticality, applies PriorityClasses with preemption for training, and uses MIG only for serving to maximize utilization. Option C is tempting because horizontal scaling and quotas seem like straightforward fixes, but the card explicitly flags buying GPUs without scheduling logic and relying solely on quotas as inadequate solutions that ignore workload heterogeneity.
Read the full bite: Propose an architectural solution for contended GPU training resources
Question 20 of 30
How does HDFS primarily achieve fault tolerance against individual node failures?
Show the answer
Answer: c · By replicating every block across multiple DataNodes
HDFS stores multiple replicas of each block, by default three, on different nodes, so a node failure loses no data and blocks are re-replicated. The NameNode holds metadata, not the actual block data.
Question 21 of 30
In a request that fans out to 50 backends and waits for all, why does a 1% per-backend slow rate cause widespread slowness?
Show the answer
Answer: a · End-to-end latency is gated by the slowest backend, so the chance at least one is slow is high
Waiting for all responses means the slowest dominates, and across 50 backends the probability at least one hits its slow tail is large (about 40% at 1% each). The mean stays low precisely because most individual calls are fast.
Question 22 of 30
Which strategy best balances fault tolerance and throughput when training a large model on spot instances?
Show the answer
Answer: b · Write sharded checkpoints to object storage every N steps, handle SIGTERM to upload an emergency checkpoint, and resume from the latest durable state on a replacement node.
The correct approach combines granular durable checkpoints with signal handling and idempotent resume, decoupling compute reliability from training progress. Relying solely on a SIGTERM-triggered upload is dangerous because a large checkpoint may not finish within the two-minute window, causing total loss of progress since the last periodic durable save.
Read the full bite: How do you adapt ML training for spot instance interruptions?
Question 23 of 30
A Spark join stage finishes only after one task processing a single hot key completes. Which fix targets the root cause?
Show the answer
Answer: b · Salt the hot key to spread its rows across partitions
Salting redistributes a dominant key's rows across many tasks, removing the straggler. Adding executors or memory does not rebalance rows that remain concentrated on one partition key.
Read the full bite: Diagnosing and fixing data skew in Spark
Question 24 of 30
How does chaos engineering fundamentally differ from load testing?
Show the answer
Answer: a · Chaos injects faults to test a resilience hypothesis, while load testing verifies performance under expected demand
Chaos engineering is hypothesis-driven fault injection to discover resilience weaknesses, whereas load testing measures performance against expected demand. They answer different questions and complement rather than replace each other.
Read the full bite: How does chaos engineering differ from other testing?
Question 25 of 30
What is the defining benefit of the publish/subscribe pattern over direct point-to-point messaging?
Show the answer
Answer: a · Publishers and subscribers are decoupled, so neither needs to know about the other
Pub/sub decouples producers from consumers via a broker, letting each side change independently and enabling fan-out. It relies on a broker rather than avoiding one, does not guarantee exactly-once ordering by default, and subscribers do not ack the publisher directly.
Question 26 of 30
Why is storing rate-limit counters in each API node's local memory a flawed design for a multi-server gateway?
Show the answer
Answer: c · Each node counts independently, so a caller can exceed the true limit by spreading requests across nodes
With per-node counters, N nodes each enforce the full limit, multiplying the effective allowance, so a shared store like Redis is needed for one global count. Local memory is fast, can hold any counter, and can model token buckets fine; the flaw is purely the lack of shared state.
Question 27 of 30
In a horizontally scaled WebSocket system, how does a pub/sub backplane enable broadcast to clients across all server nodes?
Show the answer
Answer: c · By propagating only the serialized payload to all nodes, which then forward it to their local connections
The backplane distributes only the serialized payload so that each node can forward it to its own locally held connections without sharing socket state. Serializing WebSocket objects or file descriptors is impossible because TCP connections and coroutine state are bound to their host process.
Read the full bite: How do you broadcast WebSocket messages to all clients across server nodes?
Question 28 of 30
In a distributed query over partitioned columnar storage, what is the main performance benefit of predicate pushdown?
Show the answer
Answer: b · It filters and prunes partitions at the source so far less data is read and transferred
Pushdown applies the filter at the scan or remote node, pruning partitions and rows before data moves, which slashes IO and network cost. Selecting only needed columns is projection pushdown, a separate optimization.
Read the full bite: Predicate pushdown and why it speeds queries
Question 29 of 30
Beyond CPU/memory/disk, which factor is most critical when capacity-planning a multi-region stateful system?
Show the answer
Answer: d · Failover headroom so surviving regions absorb a lost region's load, plus replication bandwidth and IOPS
Multi-region stateful systems must reserve headroom so losing a region does not overload the rest, and replication bandwidth plus IOPS often bound throughput before CPU does. Running every region at 100% leaves no room for failover and guarantees collapse on a region loss.
Read the full bite: Capacity planning for distributed stateful systems
Question 30 of 30
Which approach best fulfills a GDPR erasure request across microservices while respecting bounded contexts and eventual consistency?
Show the answer
Answer: d · Publish a durable erasure event, let each service independently delete or anonymize its own data, and reconcile
B is correct because GDPR erasure in distributed systems requires asynchronous, service-local handling via durable events rather than tight coupling. A is tempting but wrong because distributed transactions force lockstep deletion, violating bounded contexts and creating fragility.
Read the full bite: How do you fulfill a GDPR erasure request across microservices?
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.