Distributed Computing Senior

Strong consistency lets replicas diverge and reconcile later automatically; prefer it when clients can tolerate reading somewhat stale values for a while.

Strong consistency orders only causally related operations locally per node; prefer it when concurrent writes never touch the same overlapping keys at all.

Causal consistency orders only causally related operations without global coordination; prefer it when you want ordering yet high availability and low latency.

Causal consistency requires every replica to agree synchronously on a total order; prefer it when correctness matters far more than availability or latency.

Linearizability and serializability are the very same guarantee under different names, so asking whether a system can be both is essentially meaningless.

Linearizability concerns multi-object transaction ordering; serializability is a recency guarantee on single objects; no system can provide both together.

Linearizability is a real-time recency guarantee on single objects; serializability concerns transactions over many objects; a system can be both.

Linearizability guarantees eventual convergence of replicas; serializability guarantees isolation of transactions; combining both is possible but never useful.

Both need one total order, but sequential consistency also respects real-time order; it is harder because clocks must be perfectly synchronized across nodes.

Both need one total order, but linearizability also respects real-time order; it is harder because it constrains even non-overlapping operations globally.

Linearizability allows reordering per process while sequential does not; sequential is harder because it demands a single global wall-clock timestamp source.

Neither requires a total order of operations at all; linearizability is harder only because it additionally requires transactions to be fully serializable.

It replaces CAP entirely by proving that consistency and availability can always coexist whenever the network is fully connected.

It states partitions never occur in practice, so systems only ever balance raw performance against the durability of stored data.

It extends CAP: if Partitioned choose A or C, Else choose Latency or Consistency; normally it is a latency-consistency tradeoff.

It extends CAP: during partitions choose A or C, Else choose Latency or Availability; normally it is a latency-availability tradeoff.

It outputs a continuous suspicion value from heartbeat-arrival statistics, instead of a fixed binary alive-or-dead timeout.

It replaces heartbeats with acknowledgements from every peer, producing a continuous value only once the whole cluster fully agrees.

It sends heartbeats more frequently than usual to detect failures faster, but still returns a simple alive-or-dead binary result.

It waits for a fixed timeout like a heartbeat but averages several rounds, giving the same binary output after multiple missed beats.

A periodic signal that nodes send to peers to confirm that they are still alive and reachable

A lock held indefinitely by one node until it voluntarily chooses to release the shared resource

A time-bound grant of a right that expires unless renewed, so failure needs no consensus

A quorum vote that elects a fresh leader whenever the current leader stops answering requests

A failure that overloads surviving nodes and spreads; load shedding drops excess requests to protect them

A failure where one node simply crashes; automatic failover reroutes its traffic to healthy replicas

A failure caused by a network partition; quorum reads are used to keep the whole system consistent

A failure that propagates via corrupted replication; checksums are used to detect and halt its spread

Omission and timing both mean a node sends arbitrary malicious messages, making them worse than Byzantine

Omission and timing describe clean halting failures that are strictly simpler to handle than crash faults

Omission drops messages and timing responds outside bounds; both are worse than crash, milder than Byzantine

Omission means a node halts silently and timing means it sends corrupted values; both equal Byzantine faults

A hot key is a shard that has crashed under load; detect via heartbeat timeouts and mitigate by promoting a follower replica to take over writes.

A hot key is one key or narrow range getting outsized traffic; detect with per-key metrics and mitigate by splitting, salting, or caching it.

A hot key is a key with an expired lease; detect through version vectors and mitigate by rerouting all traffic to a dedicated strongly consistent leader.

A hot key is a key that is never accessed; detect with per-key metrics and mitigate by merging cold shards together and disabling replication for it.

Writes pass head to tail along a chain and reads come from the tail, giving strong consistency but adding latency and slower recovery on failures.

Writes and reads both hit the middle node of the chain, balancing load evenly but sacrificing durability whenever any single node in the chain fails.

Writes go to any node and propagate backward to the head, giving eventual consistency with very low latency but frequent conflicts needing reconciliation.

Writes are broadcast to all nodes at once and reads use quorum voting, maximizing availability but reducing overall write throughput under heavy load.

Anti-entropy is a compression scheme for logs; read-repair discards old versions during reads and Merkle trees compact the write-ahead log into snapshots.

Anti-entropy is a locking protocol between replicas; read-repair blocks writes during reads and Merkle trees enforce a total ordering of all updates.

Anti-entropy is a background sync of replicas; read-repair updates stale copies during reads and Merkle trees pinpoint diverging ranges cheaply.

Anti-entropy is a leader election method; read-repair chooses a new coordinator on reads and Merkle trees track which node holds the write lease now.

Sloppy quorum requires a strict majority of home nodes for writes and hinted handoff replays a full log to rebuild any node that fell permanently behind.

Sloppy quorum accepts writes on any reachable nodes during failures and hinted handoff holds them temporarily to deliver back to the home node later.

Sloppy quorum elects a temporary leader to serialize writes and hinted handoff caches responses at the coordinator to speed up repeated key lookups.

Sloppy quorum blocks all writes until every home replica responds and hinted handoff queues reads so clients always see the most recently committed value.

They synchronize every node's clock via NTP so that logical counters are no longer needed.

They replace physical clocks entirely with vector clocks to guarantee a total global ordering.

They use GPS and atomic clocks to remove all uncertainty from the timestamps across nodes.

They combine physical time with a logical counter to preserve causality with near-real-time values.

Skew is the rate of divergence, drift is the difference; TrueTime avoids both by using plain vector clocks.

Skew is the difference between clocks, drift is how fast they diverge; TrueTime bounds and waits out this uncertainty.

Skew and drift are the very same measure; TrueTime eliminates them completely using only atomic clocks.

Skew is network latency, drift is packet loss; TrueTime corrects them by retrying commits until synced.

An API returning a logical Lamport counter; Spanner increments it per transaction to totally order commits without physical clocks.

An API returning a time interval with bounded error; Spanner waits out that uncertainty before committing to guarantee correct ordering.

An API returning a single exact timestamp from atomic clocks; Spanner uses it to skip locking and commit transactions instantly.

An API returning a time interval with bounded error; Spanner picks the earliest bound and commits immediately without any waiting.

Data types whose merge relies on last-writer-wins timestamps only, so replicas discard all but the newest concurrent update always.

Data types that use a central lock manager to serialize merges, so replicas converge to the same state regardless of update order.

Data types that broadcast every operation through a leader node, so replicas apply updates in a single globally agreed order.

Data types whose merge is commutative, associative and idempotent, so replicas converge to the same state regardless of update order.

Consensus fails because network partitions permanently split nodes into groups that can never reconcile their divergent states.

No protocol reaches consensus because Byzantine nodes send conflicting messages that end up corrupting every honest node's decision.

Consensus is impossible because asynchronous clocks drift apart and nodes can never agree on a shared global ordering of events.

No deterministic protocol can guarantee consensus when a node may crash, since a slow node is indistinguishable from a failed one.

Raft avoids the need for a leader entirely, letting all nodes propose values symmetrically, which removes the single point of failure.

Raft requires fewer nodes to reach a quorum than Paxos does, so Raft achieves consensus faster under the same failure conditions.

Raft tolerates Byzantine failures while Paxos only handles crash faults, so Raft is safer for adversarial production environments.

Raft decomposes consensus into clear subproblems like leader election and log replication, making it easier to implement correctly.

A unique identifier assigned to each client request so that duplicate commands are never applied more than once.

A counter of committed log entries that is used to detect when a follower has fallen behind the current leader's state.

A fixed time interval after which every node must restart and re-synchronize its entire log with the rest of the cluster.

A monotonically increasing number that orders leadership periods and lets nodes reject stale messages from older leaders.

Safety means nothing bad happens; liveness means something good eventually happens; FLP shows you can't guarantee both asynchronously.

Safety means messages arrive in order; liveness means they arrive quickly; FLP shows ordering and speed conflict once nodes fail.

Safety means data gets replicated; liveness means data is durable; FLP shows replication and durability trade off in async systems.

Safety means the system stays available; liveness means it stays consistent; FLP shows these two cannot coexist during a partition.

Basic Paxos tolerates Byzantine faults per instance; Multi-Paxos drops that guarantee to gain speed on trusted replicas.

Basic Paxos agrees on many values at once; Multi-Paxos restricts each round to a single value to strengthen safety guarantees.

Basic Paxos needs a leader for every round; Multi-Paxos removes the leader so acceptors decide values independently in parallel.

Basic Paxos agrees on one value per instance; Multi-Paxos elects a stable leader to skip prepare phases across many entries.

ZAB is a crash-recovery atomic broadcast protocol guaranteeing primary-order delivery, tailored for ZooKeeper's state updates.

ZAB is a leaderless voting protocol where clients directly commit, unlike Paxos and Raft which centralize all writes on a leader.

ZAB is a Byzantine-tolerant protocol that signs every message, unlike Paxos and Raft which assume only simple crash failures.

ZAB is a gossip-based protocol that spreads updates eventually, unlike Paxos and Raft which require strict synchronous quorums.

A leader computes results and pushes final state snapshots down to all of its follower replicas.

Replicas execute the same deterministic commands in the same log order, reaching identical states.

Each replica logs commands locally and resolves any ordering conflicts using vector clock values.

Replicas run independent commands and periodically merge their divergent states into a single one.

It only guarantees delivery, so it stays strictly weaker than actually solving consensus.

It orders messages by timestamps, which fully sidesteps the need for any agreement step.

Delivering messages in one agreed identical order requires nodes to agree on that order.

It broadcasts messages faster than consensus by avoiding any form of leader coordination.

Processes broadcast their states, and the initiator selects the most recent consistent combination.

Each process periodically saves its state and messages, then merges them by vector clock timestamps.

A process records its state on a marker, then records incoming channel messages until markers arrive.

A coordinator freezes all processes simultaneously and copies their states using one global clock.

Three-phase pre-prepare/prepare/commit voting tolerates f faulty of 3f+1 nodes.

Leader-based log replication tolerates f crashed nodes out of 2f+1 total nodes.

Two-phase coordinator voting tolerates f faulty nodes out of 2f+1 total nodes.

Proof-of-work mining rounds tolerate any minority fraction of the nodes acting maliciously here.

Both provide identical atomicity, but Sagas need a central coordinator while 2PC does not.

Sagas give strong atomicity via locking; 2PC favors availability using compensating actions.

2PC gives strong atomicity via locking; Sagas favor availability using compensating actions.

2PC avoids locking for higher availability; Sagas block resources to ensure strict atomicity.

At-least-once may deliver duplicates; exactly-once layers deduplication and idempotency on top of retries.

At-least-once needs no acknowledgements; exactly-once is guaranteed natively by most network transport layers.

At-least-once sends once without retries; exactly-once retransmits packets until the receiver finally confirms.

At-least-once drops messages on failure; exactly-once uses TCP acknowledgements to guarantee single delivery.

Choreography commits every step in one transaction; orchestration splits steps across several independent transactions.

Choreography uses a central coordinator issuing commands; orchestration lets services react to events fully independently.

Choreography coordinates via events with no central controller; orchestration uses a coordinator directing each step.

Choreography relies on a distributed lock per step; orchestration relies on compensating events broadcast to services.

It replaces the coordinator with a quorum vote so a majority of nodes can always commit without blocking.

It removes the prepare phase and lets each node commit locally, reconciling any conflicts asynchronously afterward.

It adds a pre-commit phase and timeouts so nodes can proceed independently if the coordinator fails.

It adds a rollback phase so any node timing out can undo commits and restart the whole protocol.

TCC commits every step atomically together; Saga splits steps but keeps a distributed lock held throughout flow.

TCC compensates with reversing transactions after commit; Saga reserves resources first and confirms or cancels them.

TCC reserves resources in a Try step, then Confirm or Cancel; Saga compensates only after committing.

TCC uses a central coordinator with locks; Saga uses events among services with no reservation phase at all.

Deadlock is detected by counting retries per node; increasing the retry limit eventually resolves any blocked cycle.

Cycles in a local commit log indicate deadlock; a central coordinator must restart every blocked node together.

Cycles in a global wait-for graph indicate deadlock; timeouts or resource ordering can prevent it.

Deadlock occurs only when clocks drift; synchronizing timestamps across all nodes fully prevents it from happening.

A lock can be acquired twice by one thread by mistake; leases add reentrancy counting and fencing tokens track the recursion depth safely.

A lock server becomes a throughput bottleneck under heavy load; leases batch the requests and fencing tokens shard the lock across partitions.

A lock without a timeout blocks forever if the client crashes; leases add retry logic and fencing tokens replay the queued operations later.

A paused process may resume after its lease expired and another holds the lock; monotonic fencing tokens let storage reject its stale write.

They use a single master database with row locking so clients see one truth; building your own just needs one shared SQL table.

They rely on client-side timeouts and retries to reach agreement; you avoid them because they add unnecessary network latency.

They broadcast state via gossip for eventual convergence; you skip them since any key-value cache gives you the same guarantees.

They run a consensus algorithm over a replicated log to offer consistent primitives; rolling your own correctly is extremely hard.

It replaces gossip with a consensus round so all nodes agree on membership, trading extra latency for much stronger consistency.

It uses TCP keepalives between every pair of nodes to detect failures instantly, avoiding the false positives of random probing.

It centralizes failure detection in one monitor that heartbeats every node, reducing the message overhead of full gossip broadcasts.

It separates failure detection from dissemination, using randomized ping and ping-req probes plus piggybacked membership updates.

Split each request across several replicas and combine their partial responses, reducing the amount of work any single node must do alone.

Send the same request to a second replica after a short delay and take whichever response returns first, cutting slow tail latencies.

Queue requests locally and send them only when a replica reports idle capacity, avoiding overload so no request ever hits a busy node.

Retry a failed request repeatedly on the same replica with growing delays until it succeeds, ensuring transient slowdowns never surface.