Senior Consistency, CAP & Consensus Interview Questions (50 MCQs)

Question 1

What exactly does the FLP impossibility result state?

Accepted Answer

In a fully asynchronous model, no deterministic algorithm guarantees both safety and termination with even one crash

Answer

Consensus is impossible in any network model, even synchronous, with one crash

Answer

With over a third Byzantine nodes, no system can keep data durable

Answer

During a partition you cannot have consistency and availability together

Question 2

How do Raft and Paxos cope with the FLP limitation in practice?

Accepted Answer

They always keep safety and guarantee liveness only during partial synchrony via timeouts

Answer

They fully break FLP by assuming a perfectly synchronous network

Answer

They sacrifice safety during partitions so they always decide

Answer

They use atomic clocks to eliminate all timing uncertainty

Question 3

Why does Spanner perform a "commit wait" before acknowledging a commit using TrueTime?

Accepted Answer

To ensure the commit timestamp is surely in the past, so timestamp order matches real time

Answer

To wait until all replicas on every continent write the data to disk

Answer

To smooth write traffic over time and prevent overload

Answer

So that potential deadlocks between transactions resolve themselves

Question 4

If TrueTime's clock uncertainty (ε) grows from 4 ms to 40 ms, what is the effect on Spanner?

Accepted Answer

Correctness holds, but each commit's latency rises due to longer commit wait

Answer

External consistency is lost and transactions may be misordered

Answer

Spanner automatically switches into eventual consistency mode

Answer

No effect, because TrueTime is used only for logging

Question 5

CockroachDB lacks atomic clocks. What does it do when a read encounters a value inside its "uncertainty interval"?

Accepted Answer

It bumps the transaction timestamp and restarts the read to see that value correctly

Answer

It ignores the value and silently returns the older version

Answer

It pauses the whole cluster until clocks are resynced

Answer

It waits the max offset on every write like Spanner

Question 6

Why is linearizability called a "local" or composable property?

Accepted Answer

If each object is linearizable on its own, the system made of them is too

Answer

Because it can only be implemented on a single local machine

Answer

Because it also guarantees serializability for multi-object transactions

Answer

Because it needs no coordination between an object's replicas

Question 7

Two on-call doctors both check "at least one other is on call" and both go off call. Under snapshot isolation, what happened?

Accepted Answer

Write skew; each wrote a different row, which SI does not detect

Answer

Dirty read; one read the other's uncommitted data

Answer

Lost update; both overwrote the very same row

Answer

A phantom read caused by a missing table index

Question 8

In a store with N=3, `W=2`, `R=2` and LWW, why is linearizability not guaranteed even without sloppy quorums?

Accepted Answer

An in-flight write may be seen by one reader and missed by a later one, unless reads repair synchronously

Answer

Because `R + W > N` mathematically creates no overlap between the sets

Answer

Because LWW always keeps the oldest write and drops newer ones

Answer

Because reads in such systems are never sent to more than one node

Question 9

A team using Cassandra `QUORUM` with hinted handoff assumes reads always see the latest write. Where is the flaw?

Accepted Answer

A timed-out write may land on some replicas without rollback, so later quorum reads can flip between old and new

Answer

`QUORUM` in Cassandra applies only to writes and reads are always `ONE`

Answer

Hinted handoff makes every read be answered directly by the coordinator

Answer

Cassandra never stores a write on more than one replica

Question 10

Why can't a new Raft leader declare a previous-term entry committed just by counting it on a majority?

Accepted Answer

It could still be overwritten by a leader with a different log; only current-term entries commit by counting

Answer

Because previous-term entries must always be stored on all nodes

Answer

Because old entries are automatically deleted once the term changes

Answer

Because only followers are allowed to count replicas

Question 11

Why does a newly elected Raft leader usually append a no-op entry at the start of its term?

Accepted Answer

To quickly commit a current-term entry and learn which earlier entries are committed

Answer

To tell clients the cluster is read-only for a while

Answer

To shrink the log ahead of the next snapshot

Answer

To sync the followers' physical clocks with its own

Question 12

Why is switching a cluster from 3 to 5 nodes in one step (without joint consensus or single-node changes) dangerous?

Accepted Answer

During transition, two disjoint majorities (old and new) may elect two leaders

Answer

Because new nodes can never receive the log from the leader

Answer

Because Raft supports a maximum of three nodes

Answer

Because all data must be wiped before the change

Question 13

A Raft node isolated for a while rejoins with a much higher term and deposes a healthy leader. Which mechanism prevents this?

Accepted Answer

Pre-Vote; the node checks a majority would vote before bumping its term

Answer

Raising the leader's heartbeat interval to several seconds

Answer

Disabling the election timeout on all followers

Answer

Using LWW to pick the leader by timestamp

Question 14

Raft leader-lease reads (serving reads without a majority round-trip) depend on what assumption?

Accepted Answer

Bounded clock drift; otherwise a new leader may be elected before the old lease expires

Answer

That all clients send requests from a single datacenter

Answer

That no writes happen at all during the lease

Answer

That followers never crash at any point

Question 15

A client sends a non-idempotent write (like `increment`) to a Raft cluster and times out. What is the risk of a naive retry, and the fix?

Accepted Answer

The first may have committed and gets applied twice; dedupe via client ID and sequence number in the state machine

Answer

No risk, since Raft guarantees timed-out writes are never committed

Answer

A retry causes permanent split brain; the cluster must be restarted

Answer

The second write is always rejected; the client's term must be raised

Question 16

What is Martin Kleppmann's core critique of Redlock for correctness-critical uses?

Accepted Answer

It produces no fencing tokens and its safety relies on timing assumptions about pauses, drift, and delay

Answer

Because it uses more than one Redis node, its throughput is very low

Answer

Because it stores locks on disk, giving high latency

Answer

Because it only works with Redis Cluster, not standalone instances

Question 17

A service gets fencing tokens from etcd but writes to S3, which checks no version condition. What is the outcome?

Accepted Answer

Fencing is useless; tokens only work if the final resource checks and rejects stale ones

Answer

etcd automatically rolls back stale writes in S3

Answer

S3 reads and compares the token from the header by default

Answer

Fencing still fully works since the etcd lock is linearizable

Question 18

In ZooKeeper, client A writes and notifies client B out of band. B reads from another follower and sees the old value. Why, and what's the fix?

Accepted Answer

ZooKeeper reads are local and may be stale; B should call `sync()` before reading

Answer

ZooKeeper replicates writes asynchronously and may lose them; enable `fsync`

Answer

B must open a new session to clear its cache

Answer

This is a bug; ZooKeeper always gives linearizable reads

Question 19

In etcd, how do reads with `--consistency=s` (serializable) differ from the default linearizable mode?

Accepted Answer

Serializable answers from the local node without quorum; faster but possibly stale

Answer

Serializable needs a majority while linearizable only reads the leader

Answer

There is no difference; only the naming differs

Answer

Serializable works only for keys attached to a lease

Question 20

You have a two-node database cluster with automatic failover. If the link between them breaks, what's the best design to avoid split brain?

Accepted Answer

Add a third witness/tie-breaker in a separate failure domain so only the majority side stays active

Answer

Have both nodes promote themselves to primary when the link drops

Answer

Shorten the heartbeat timeout so failover happens faster

Answer

Send heartbeats over the same link at double frequency

Question 21

You spread a five-node Raft cluster across datacenters. Which layout survives losing any single datacenter?

Accepted Answer

2-2-1 across three datacenters

Answer

3-2 across two datacenters

Answer

4-1 across two datacenters

Answer

All 5 in one datacenter across two zones

Question 22

In Basic Paxos, two proposers keep preempting each other with higher numbers and nothing is chosen. What's the common fix?

Accepted Answer

Elect a distinguished leader (Multi-Paxos) plus randomized backoff

Answer

Reduce the acceptors to a single node for speed

Answer

Remove the prepare phase and send accept directly

Answer

Choose the value based on the proposers' physical timestamps

Question 23

In Paxos, if a proposer sees in promise replies that some acceptors already accepted a value, what must it do?

Accepted Answer

Propose the value with the highest accepted proposal number, not its own

Answer

Propose its own value with a higher number to replace it

Answer

Pick whichever value the most acceptors accepted

Answer

Abort the whole process and wait for another proposer

Question 24

To tolerate f Byzantine (possibly lying) nodes in consensus, how many nodes are needed, and where does Raft stand?

Accepted Answer

`3f+1` nodes; Raft tolerates only crash faults, not Byzantine ones

Answer

`2f+1` nodes; Raft fully tolerates both kinds of faults

Answer

`f+1` nodes; Raft tolerates Byzantine faults only with atomic clocks

Answer

`4f` nodes; Raft becomes Byzantine-safe by encrypting messages

Question 25

Despite using 2PC, how does Spanner mitigate blocking from a coordinator crash?

Accepted Answer

Coordinator and participants are each Paxos groups, so decision state is replicated and survives failover

Answer

Spanner uses 3PC instead of 2PC, which never blocks

Answer

Participants unilaterally commit after a timeout

Answer

Spanner does not support cross-shard transactions at all

Question 26

In 3PC, a partition hits where some participants got pre-commit and others didn't. What's the worst outcome?

Accepted Answer

Each side decides differently on timeout (commit vs abort), violating atomicity

Answer

All participants block forever, exactly like 2PC

Answer

The coordinator auto-detects the partition and aborts all

Answer

The transaction commits everywhere since pre-commit suffices

Question 27

In a saga, the "send SMS to customer" step can't be compensated. Where should it go in the saga's order?

Accepted Answer

After the pivot transaction, as a retriable step repeated until success

Answer

At the very start of the saga so the customer knows sooner

Answer

In parallel with all the other steps at once

Answer

Before any step that might possibly fail

Question 28

A saga reserves stock, then compensates after payment fails. Meanwhile another user saw "out of stock". Which countermeasure fits?

Accepted Answer

A semantic lock or tentative reservation (`RESERVED` status) others can tell apart from a final sale

Answer

Converting the saga into a 2PC across every microservice

Answer

Removing the compensating action to avoid stock changes

Answer

Raising the payment timeout so fewer failures happen

Question 29

A service commits to PostgreSQL, then publishes to Kafka. If it crashes in between, what happens, and what's a robust fix?

Accepted Answer

The event is never published; an outbox in the same transaction plus CDC (e.g. Debezium) fixes it

Answer

Kafka automatically recovers the event from the database WAL

Answer

PostgreSQL rolls back since Kafka never acknowledged it

Answer

Reverse the order, Kafka first then DB, which fully solves it

Question 30

A Flink streaming job with "exactly-once" checkpoints calls an external webhook per event. After a failure and restore from checkpoint, what can happen?

Accepted Answer

Webhooks since the last checkpoint fire again unless the sink is transactional or idempotent

Answer

No webhook repeats since exactly-once covers every output

Answer

All webhooks since the job's very start are resent

Answer

Flink automatically revokes the earlier calls from the webhook

Question 31

A consumer keeps message IDs for dedupe only 10 minutes. Which scenario causes duplicate processing?

Accepted Answer

After a long outage, the producer resends a message 30 minutes later

Answer

Two messages with different IDs arrive within one second

Answer

The broker loses the message right after the ack

Answer

The consumer processes the message in under a millisecond

Question 32

Two requests with the same idempotency key arrive concurrently. What's wrong with "SELECT first, process if absent"?

Accepted Answer

Both miss the key and both process; insert the key under a unique constraint first, then process

Answer

A SELECT on the key table always causes a deadlock

Answer

The second request always receives the first one's response

Answer

No problem, since idempotency keys are inherently thread-safe

Question 33

What is the strongest consistency model that can remain available (in the CAP sense) during a network partition?

Accepted Answer

Causal consistency (with session guarantees for sticky clients)

Answer

Linearizability

Answer

Sequential consistency

Answer

Strict serializability

Question 34

Which critique of the common use of CAP to classify databases is valid?

Accepted Answer

CAP only models single-register linearizability and full partitions, ignoring latency, partial failure, and middle models

Answer

CAP proves every database must permanently pick exactly two of three

Answer

CAP is only valid for single-node relational databases

Answer

CAP shows AP systems offer no consistency guarantees at all

Question 35

You run a strongly consistent database with replicas in Europe, US, and Asia, and there's no partition. Why are writes still slow?

Accepted Answer

Each write needs majority acks, at least one intercontinental round-trip (the EC side of PACELC)

Answer

Strong consistency only costs during partitions, so this is a bug

Answer

Because replicas heavily compress data before writing

Answer

Because intercontinental clock skew fully blocks writes

Question 36

In a vector-clock store with one entry per client, what goes wrong with millions of clients, and what's the common fix?

Accepted Answer

Vectors grow unbounded; use server replica IDs (or dotted version vectors) instead of client IDs

Answer

Vectors overflow; switch to 128-bit integers

Answer

Clients can no longer read; LWW must replace them

Answer

No problem, since vector clocks have a fixed size

Question 37

A replica returns after days of downtime. Why is relying only on read repair insufficient to converge it?

Accepted Answer

Unread keys never get repaired and hints may have expired; anti-entropy repair is required

Answer

Read repair only runs on the leader and never touches the replica

Answer

Read repair wipes all data on the returning replica

Answer

Read repair only works for writes under a second old

Question 38

In Cassandra, a replica is down longer than `gc_grace_seconds` and then rejoins. What's the danger?

Accepted Answer

Delete tombstones were purged elsewhere, so deleted data resurrects from the old replica

Answer

The replica automatically rejects all new data

Answer

The cluster locks until the replica is manually wiped

Answer

All new writes are lost after the replica rejoins

Question 39

In a replicated cart, a user removes an item on one replica while concurrently adding it on another. What does an OR-Set (Observed-Remove Set) yield?

Accepted Answer

The item stays; remove only deletes add-tags it observed (add-wins)

Answer

The item is removed since remove always beats add

Answer

The outcome depends on the two operations' physical timestamps

Answer

Both operations are rejected and the user gets an error

Question 40

A service checks lease expiry by comparing `expiresAt` (a wall-clock timestamp from the lock server) with its local clock. What's the core problem?

Accepted Answer

It depends on two machines' clocks agreeing; measure duration on a local monotonic clock with a safety margin

Answer

Timestamps cannot be sent in JSON with enough precision

Answer

The lock server should never reveal the expiry to clients

Answer

Timestamp comparison causes a heavy spike in CPU usage

Question 41

A three-node etcd cluster's write throughput is maxed out. What does growing it to 7 nodes do, and what's better?

Accepted Answer

Throughput gets worse due to a larger quorum; batch writes or shard data across multiple consensus groups instead

Answer

Throughput rises about 2.3x since writes spread across nodes

Answer

Throughput stays the same but reads become slower

Answer

etcd automatically switches to AP mode above 5 nodes

Question 42

Instances elect a leader via a PostgreSQL row using `UPDATE ... SET owner=?, expires_at=? WHERE expires_at < now()`. What's essential to make leader actions safe?

Accepted Answer

An increasing `epoch` in that row, sent by the leader with every write and checked downstream

Answer

Raising `expires_at` to several hours so the leader rarely changes

Answer

Running the query at `READ UNCOMMITTED` for extra speed

Answer

Having every instance `SELECT` the row once more before working

Question 43

An async-replicated primary crashes after acknowledging some writes, and a lagging replica is promoted. Beyond losing those writes, what subtler risk exists?

Accepted Answer

Lost auto-increment IDs get reissued and collide with data external systems (e.g. cache or Redis) already saw

Answer

The new replica automatically drops every table

Answer

The old primary always merges its data correctly on return

Answer

All clients stay connected to the old primary forever

Question 44

A global signup service on a multi-leader AP database must guarantee unique usernames. What's the right approach?

Accepted Answer

Reserve usernames through a linearizable path (consensus or single leader per key); uniqueness needs coordination

Answer

Use LWW so the second username automatically replaces the first

Answer

Use a G-Set CRDT, which deduplicates entries by itself

Answer

Check the local replica for the username before registering

Question 45

A transactional Kafka producer stalls for a long time and a replacement starts with the same `transactional.id`. How does Kafka stop the old "zombie" from writing?

Accepted Answer

Via `initTransactions` bumping the producer epoch; brokers reject requests with an older epoch

Answer

By auto-deleting the topic and recreating it for the new instance

Answer

By comparing both producers' wall-clock timestamps and keeping the newer

Answer

By allowing both producers and deduplicating in the consumer

Question 46

A Raft follower has fallen so far behind that the entries it needs were removed from the leader by log compaction. What does the leader do?

Accepted Answer

Sends a state-machine snapshot via `InstallSnapshot`, then resumes replication after it

Answer

Permanently removes the follower and adds a fresh node

Answer

Cancels compaction and recovers deleted entries from disk

Answer

Asks the follower to re-fetch the entries from clients

Question 47

Why do Kubernetes controllers using `Lease`-based leader election usually exit the whole process when they lose the lease?

Accepted Answer

So in-flight work that assumed leadership stops at once and two leaders don't act together

Answer

Because Kubernetes can't issue a new lease without a restart

Answer

To discard cached memory and reduce RAM usage

Answer

Because etcd permanently blocks the process after lease expiry

Question 48

A database is serializable but not strictly serializable. A user places an order, gets success, immediately opens the orders page, and doesn't see it. Is that allowed?

Accepted Answer

Yes; serializability only promises some serial order, and the read may be ordered before the write

Answer

No; serializability always guarantees real-time transaction order

Answer

No; that's only possible under eventual consistency, so it's a bug

Answer

Yes, but only if both transactions touch the same row

Question 49

In chain replication, writes enter at the head and propagate down the chain. Where are strongly consistent reads served, and why?

Accepted Answer

From the tail, since only writes reaching it are replicated to every node and acknowledged

Answer

From the head, since the newest writes reach it first

Answer

From the middle node, to balance load between head and tail

Answer

From any random node, since all nodes are always identical

Question 50

Why do distributed databases use HLC rather than pure Lamport clocks for snapshot reads at a given time (e.g. `AS OF SYSTEM TIME '-10s'`)?

Accepted Answer

HLC tracks wall time closely so it maps to real time, while Lamport counters carry no time meaning

Answer

Because Lamport clocks don't preserve causal order at all

Answer

Because HLC doesn't need timestamps carried in messages

Answer

Because HLC fully detects concurrency like a vector clock