Search DistillSys

Find a concept

Type at least two characters to search lessons, designs, papers, and interview prep.

Phase 6 · Interview mode

Reason out loud.

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.

Refresh: Distributed systems fundamentals →
02FundamentalConsistency

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.

Refresh: CAP theorem →
03FundamentalReplication

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.

Refresh: Replication →
04IntermediateConsistency

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.

Refresh: Quorums →
05IntermediateReliabilityScenario

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.

Refresh: Failure and retry patterns →
06IntermediatePartitioning

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.

Refresh: Consistent hashing →
07SeniorConsensusScenario

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.

Refresh: Raft consensus →
08SeniorPartitioningScenario

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.

Refresh: Consistent hashing →
09SeniorTransactionsScenario

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.

Refresh: Two-phase commit →
10SeniorMessaging

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.

Refresh: Distributed logs →
11Staff+ArchitectureScenario

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.

Refresh: PACELC →
12Staff+ArchitectureScenario

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.

Refresh: Replication →
13Staff+ReliabilityScenario

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.

Refresh: Failure and retry patterns →
14ManagerLeadershipScenario

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.

Refresh: Consistency models →
15ManagerLeadershipScenario

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.

Refresh: Distributed systems fundamentals →