Interview questions

Interview questions (with the counter-questions you'll get)

Q1. Explain the CAP theorem.

They're testing: whether you can state it precisely, not as a slogan.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** In a distributed system where the network can drop messages between nodes, you can't guarantee both linearizable consistency and availability (every non-failing node answering every request) during a partition. Since partitions can't be ruled out, the real choice is how to behave during one: refuse some requests to stay consistent (CP), or keep answering and accept stale or conflicting data (AP). When there's no partition, you can have both.
3
4**Counter-questions:**
5- *"So what's a CA system?"* → A single machine, or a system that simply fails during a partition. For distributed systems, P isn't something you get to leave out.
6- *"Who proved it?"* → Brewer conjectured it in 2000; Gilbert and Lynch proved it in 2002.
7
8**Trap:** "pick any two of three".

Q2. What's the difference between strong and eventual consistency?

They're testing: clear definitions and trade-offs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Strong consistency (linearizability) makes the system behave like a single copy: once a write is confirmed, every read anywhere sees it. Eventual consistency only promises replicas converge if writes stop, so reads can be stale meanwhile. Strong costs latency and availability during failures; eventual is fast and available but needs conflict handling.
3
4**Counter-questions:**
5- *"How long is 'eventually'?"* → Not bounded by the definition; in practice measure replication lag, typically milliseconds to seconds.
6
7**Trap:** describing eventual consistency as "wrong data".

Q3. Give an example of choosing CP vs AP.

They're testing: applying the theory.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A wallet balance or seat booking should be CP: during a partition, refuse rather than risk double spending or double booking. A shopping cart or likes counter can be AP: always accept the action and merge later. Amazon's Dynamo paper used the cart as its example of never refusing a write.
3
4**Counter-questions:**
5- *"What does the user see in the CP case?"* → An error or "try again shortly". You design the message and the retry.
6
7**Trap:** choosing one for the whole system.

Q4. What is PACELC?

They're testing: knowing beyond CAP.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Abadi's extension: if there's a partition, choose availability or consistency; else, choose latency or consistency. It highlights that coordination costs latency even on healthy days, which affects every request, while partitions are rare. Dynamo-style systems are PA/EL by default; fully ACID coordinating systems are PC/EC.
3
4**Counter-questions:**
5- *"Why does consistency cost latency without failures?"* → Replicas must exchange messages before confirming, adding at least a round trip, which is large across regions.
6
7**Trap:** not knowing the "else" half.

Q5. What is linearizability?

They're testing: precision.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Every operation appears to take effect at a single instant between its start and end, and all clients see one order consistent with real time. Practically: after a write is confirmed, no read anywhere returns an older value. It's what "consistency" means in CAP.
3
4**Counter-questions:**
5- *"How is it different from serializability?"* → Serializability is about transactions over many items behaving as if run one at a time, in some order; linearizability is about single operations respecting real-time order. A system can have one without the other; "strict serializability" combines them.
6
7**Trap:** using linearizable and serializable as synonyms.

Q6. What are read-your-writes and monotonic reads? Why do they matter?

They're testing: practical, cheaper guarantees.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Read-your-writes guarantees a user sees their own updates; monotonic reads guarantee a user never sees data go back to an older state. They fix the bugs users actually notice with replicas, like "my edit disappeared", without the cost of full strong consistency. Implement them by reading from the leader after writes or by log position, and by sticking a user to one replica.
3
4**Counter-questions:**
5- *"What about causal consistency?"* → It ensures effects are never seen before their causes, like a reply before its message; it can stay available during partitions.
6
7**Trap:** jumping to strong consistency for everything.

Q7. How do you handle conflicts in an AP system?

They're testing: what happens after "accept writes everywhere".

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Options: last-write-wins by timestamp (simple, but silently loses writes and depends on clocks), keeping all versions and merging in the application or asking the user, or using CRDTs designed to merge automatically, like counters and sets. Choose by data: counters as CRDTs, carts as merged sets, profile fields maybe last-write-wins.
3
4**Counter-questions:**
5- *"Why are CRDTs not used for everything?"* → They only exist for certain data types and operations, and some invariants (like "balance never negative") can't be guaranteed without coordination.
6
7**Trap:** not knowing last-write-wins loses data.

Q8. Do quorums give strong consistency?

They're testing: depth.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** W + R > N ensures read and write sets overlap, so reads usually see the latest write, but it doesn't guarantee linearizability by itself: concurrent writes, partially failed writes and sloppy quorums can still produce stale or out-of-order reads. True linearizability needs consensus or extra coordination, like read repair before returning.
3
4**Counter-questions:**
5- *"Then why use quorums?"* → They give tunable, usually-consistent reads with good availability and no single leader, which suits many workloads.
6
7**Trap:** "W + R > N means strong consistency, full stop".

Q9. How would you design a wallet that works across two regions?

They're testing: applying CAP to money.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Give each wallet a single home region with a strongly consistent leader, or use a consensus-based store across regions. Spends go to that leader; during a partition, the side that can't reach it refuses spends. Display balances can be read from a local replica with a "may be slightly out of date" understanding, but the decision to spend always uses the authoritative balance. Another approach is to split the balance into per-region allowances that can be spent locally, rebalanced when connected.
3
4**Counter-questions:**
5- *"Cross-region writes are slow. Acceptable?"* → For money, yes; correctness matters more than 100 ms. Keep it to the spend itself.
6
7**Trap:** an AP wallet.

Q10. Is your favourite database CP or AP?

They're testing: nuance.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Often it depends on configuration and how you use it. A single-leader database with synchronous replication and proper fencing behaves CP; read from asynchronous followers and those reads behave AP. Cassandra can act more CP or more AP per query through consistency levels. I'd describe the specific behaviour during a partition rather than give a label.
3
4**Counter-questions:**
5- *"Where would you look to know for sure?"* → The documentation on replication and failover behaviour, and independent testing like the Jepsen analyses.
6
7**Trap:** confidently labelling a database without conditions.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 16.1 Two meanings | Q5 |
18| 16.2 Strong consistency | Level 1A.2, Level 2.1, Q2, Q5 |
19| 16.3 Eventual consistency | Level 1A.1, Level 3.3, Level 3.4, Q2, Q7 |
20| 16.4 Session guarantees | Level 1A.3, Level 1A.4, Q6 |
21| 16.5 Partitions | Level 2.4, Level 3, Q1 |
22| 16.6 CAP | Level 1B.1, Level 1B.2, Q1 |
23| 16.7 CP vs AP | Level 3, Level 4, Q3, Q10 |
24| 16.8 PACELC | Level 2.1, Q4 |
25| 16.9 Quorums | Level 1B.3, Level 2.2, Level 2.3, Q8 |
26| 16.10 Per feature | Level 5, Q9 |
27
28---

16. Consistency and CAP