Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
System Design · Question Set
CAP Theorem & Consistency Models interview questions for placements and exams.
Questions
15
Included in this set
Subject
System Design
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for System Design.
When a partition occurs, the system cannot synchronously coordinate all replicas. You either reject or block some requests to keep data consistent, or serve all requests and risk divergence. That is the core trade-off at partition time.
If partition: choose C (reject writes) OR choose A (accept, reconcile later).
For complete preparation, combine this set with full subject-wise practice for System Design. You can also explore other subjects and sets from the links below.
Split write and read concerns. A primary region handles consistent writes and emits events. Downstream read models and geo replicas are built asynchronously for low-latency reads near users. During partitions, writes may be constrained to the primary (CP), while reads use replicas with eventual or bounded staleness (AP). Clear freshness headers and cache hints set user expectations. Backfill and replays keep read models correct over time.
Write → Event Bus → Regional Read Model → CDN/Cache
Consistency is a single, up-to-date view across replicas. Availability means non-failing nodes return a response. Partition tolerance means the system withstands dropped or delayed messages and still operates.
C: linearizable view A: non-error response P: operation despite partitions
Feeds tolerate short-term inconsistency more than write rejection. Accepting writes keeps the product responsive. Background processes repair or order events later, while clients show freshness hints.
Write → log append locally → async replicate → reconcile ordering
Linearizability is a strong single-object guarantee: every operation seems to take effect instantaneously between call and return, shared by all clients. It is stricter than sequential consistency.
Put(x=1); later any get(x) returns 1 unless overwritten after
Monotonic reads ensure a client does not see older versions after seeing a newer one. Read-your-writes ensures the writer sees its own updates. Causal preserves happens-before. Eventual gives no strict bound.
Client A sees v2 → later should not see v1 under monotonic reads
If read quorum R and write quorum W intersect (sum greater than N), at least one replica in the read set has the latest write. That gives strong single-row semantics when paired with versioning.
N=5, W=3, R=3 → 3+3>5 ensures overlap
CRDT types define associative, commutative, and idempotent merge operations. Divergent states can be merged deterministically to the same result across replicas without coordination.
G-Counter: state = vector; merge = element-wise max; value = sum
Vector clocks track per-process counters. By comparing vectors you can tell if one event happened-before another or if they are concurrent. Lamport clocks give only a partial order.
If v1 <= v2 and not equal → v1 happened-before v2
Bounded staleness offers a tunable bound on how far behind a replica can be. It trades strictness for predictable freshness, useful for geo-reads with SLAs.
Replica lag <= 5 seconds or <= 2 versions
Leaderless systems accept writes to multiple replicas and reconcile on reads or via background repairs. Leader systems centralize ordering through a single primary but need failover when it dies.
Client writes to N replicas with W quorum; read reconciles with R quorum
At-least-once means duplicates can occur. Assign a stable idempotency key per user intent or per message. Consumers record processed keys and outcomes so replays or retries are safe. Side effects become repeatable. This keeps availability high while bounding correctness issues under partitions or crashes.
If key seen → return stored result; else process and store outcome
Money transfers and inventory holds for limited stock often choose CP. If replicas cannot agree, the system rejects or blocks requests rather than risk double spending or overselling. Users may see a retry prompt, but data stays correct. You reduce blast radius and avoid costly reconciliation later.
Reserve(item): if quorum fail → 409 or retry after
Keep per-item version vectors or last-write-wins timestamps. On heal, merge carts per user by resolving conflicts item-wise: choose higher version, or sum quantities with caps, or surface conflicts to users. Log all merges for audit. Rebuild secondary indexes from the merged truth and invalidate related cache keys. Notify clients to refresh.
merge(item): if vA>vB → pick A; if concurrent → rule: max(qty) or user confirm
Use fault injection to drop, delay, and reorder messages. Run Jepsen-style workloads that assert invariants such as no lost updates and monotonic reads per client. Measure replica lag, quorum behavior, and read-your-writes. Add shadow traffic and verify traces across regions. Document observed anomalies and ensure they match your chosen model.
Chaos: partition A|B for 5 min; run writes; validate invariants post-heal