Practice the decisions behind reliable systems—not trivia. Form an answer, state your assumptions, then reveal the reasoning and the follow-up signal an interviewer is listening for.
Question bank
Choose your depth
Showing 15 questions
01FundamentalFoundations
Why is a partial failure harder to handle than a total process crash?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
A caller cannot reliably distinguish a slow dependency, a lost request, a lost response, and a crashed process. The operation may have succeeded even when the caller times out, so recovery needs deadlines, operation identity, and safe retry semantics.
During a network partition, what choice does CAP force a replicated system to make?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
For operations that cross the partition, the system must either reject or delay some work to preserve consistency, or accept work on both sides and allow temporary inconsistency. CAP does not require choosing consistency or availability during normal operation.
What does replication improve, and what does it not guarantee by itself?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Replication can improve durability, read capacity, locality, and availability. It does not by itself establish which copy is authoritative, provide consensus, prevent stale reads, or define conflict resolution.
Why does R + W > N not automatically guarantee linearizability?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Overlap only ensures a read quorum intersects a successful write quorum. The read still needs version metadata and a rule for selecting the newest valid value, while concurrent writes, sloppy quorums, clock assumptions, and failures can violate real-time ordering.
A payment request times out after reaching the server. How would you make retrying safe?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Give the logical payment a stable idempotency key, persist the key and outcome atomically with the side effect, and return the recorded outcome for duplicates. Bound retries with deadlines, backoff, jitter, and a retry budget; do not assume a timeout means failure.
What problem does consistent hashing solve, and why are virtual nodes useful?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
It limits key movement when membership changes by moving only neighboring ranges. Virtual nodes give each physical node many positions on the ring, smoothing uneven distribution and allowing capacity-weighted ownership, at the cost of more metadata and range movement.
A Raft leader commits a write, then crashes before responding. What should the client do?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
The result is ambiguous to the client but committed in the cluster. The client may retry through the new leader using a stable operation ID or client sequence number; the state machine must deduplicate the retry and return the original result rather than apply it twice.
One shard receives 80% of traffic. How do you diagnose and mitigate it?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Measure load by key and operation, identify whether the cause is a hot key, poor partition key, range hotspot, or uneven capacity, then choose a targeted response: cache or replicate reads, split or salt the keyspace, isolate tenants, rate-limit producers, or redesign the access pattern. Rebalancing alone does not split one indivisible hot key.
What happens when a two-phase commit coordinator fails after participants prepare?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Prepared participants have promised not to abort independently and may remain blocked while holding locks or reserved resources. Recovery requires the durable coordinator log, a replicated coordinator, or a termination protocol; the core availability cost is uncertainty between prepare and the final decision.
How do you design an effectively-once outcome on top of at-least-once delivery?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Treat duplicate delivery as normal. Use a stable event ID and make the state change and consumed-ID record atomic, or make the operation naturally idempotent. Commit the consumer offset only after the durable outcome, and make external side effects independently deduplicated or transactional.
Design a multi-region write path for a product that needs low latency and strict uniqueness.
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Start by making the invariant explicit. Route uniqueness-sensitive operations to one consensus group or home region, while allowing local reads and commutative or partitioned writes elsewhere. Define failure behavior, fencing, conflict policy, RPO/RTO, and what the product does when the authority region is unreachable.
How would you roll out an incompatible data-model change across many services without downtime?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Use an expand-and-contract sequence: introduce backward-compatible storage and readers, dual-write or backfill with observability, migrate traffic, verify invariants, then remove the old representation. Every step must tolerate mixed versions and be independently reversible.
A dependency slows down and retries are causing a cascading failure. What control loop do you introduce?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Propagate deadlines, cap concurrency, add jittered backoff and retry budgets, trip circuit breakers on useful signals, shed low-priority work, and preserve capacity for recovery probes. Validate the loop with queue depth, saturation, tail latency, and retry amplification—not only error rate.
How do you decide whether a feature really needs strong consistency?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Translate consistency into user-visible invariants and business risk: what stale or conflicting state is possible, who is harmed, how it is detected, and whether it can be repaired. Compare that cost with the latency, availability, operational, and regional constraints of stronger coordination.
During a distributed-systems incident, how do you balance recovery speed with data safety?
↳ State the invariant, failure assumption, and trade-off before revealing the answer.
Reveal answer+
Declare the protected invariant, establish one incident authority, stop uncontrolled changes, and choose reversible mitigations that reduce blast radius. Separate service restoration from reconciliation, record ambiguous operations, communicate the customer impact, and define evidence required before relaxing safety controls.