Skip to content

Consistency Patterns

With multiple copies of the same data, we must choose how to synchronize them so clients have a consistent view. (Recall: consistency = every read receives the most recent write or an error.)

There are three main patterns, ranging from strongest to weakest.

Weak Consistency

  • After a write, reads may or may not see it. A best-effort approach is taken.
  • Seen in systems like memcached.

  • Works well for real-time use cases: VoIP, video chat, real-time multiplayer games.

  • Example: on a phone call, if you lose reception for a few seconds, you don't hear what was said during the gap when you reconnect.

Eventual Consistency

  • After a write, reads will eventually see it (typically within milliseconds).
  • Data is replicated asynchronously.
  • Seen in systems like DNS and email.
  • Works well in highly available systems (pairs with the AP choice in CAP).

Strong Consistency

  • After a write, reads will immediately see it.
  • Data is replicated synchronously.
  • Seen in file systems and RDBMSes.
  • Works well in systems that need transactions.

Summary table

Pattern Read-after-write Replication Typical systems Best for
Weak Maybe Best-effort Memcached Real-time, lossy media
Eventual Eventually (ms) Async DNS, email High availability
Strong Immediately Sync RDBMS, file systems Transactions

Common Interview Questions

Design a key-value store (choose a consistency model)

Why it's asked here: the interviewer wants you to pick weak/eventual/strong consistency for a concrete system and justify it.

Key points to discuss:

  • Map the model to the use case: strong for money, eventual for caches/feeds, weak for lossy real-time.

  • Explain read-after-write behavior for each pattern.

  • Sync vs async replication and how it determines the consistency level.
  • Discuss how to upgrade consistency when needed (e.g., quorum reads).
flowchart LR
    W[Write] --> M[Master]
    M -->|synchronous| R[Replica]
    R -->|strong| C[Read sees write]
    M -.asynchronous.-> R2[Replica 2]
    R2 -->|eventual| E[Read may lag]
Design Google Docs (real-time collaboration)

Why it's asked here: concurrent edits are a consistency problem — how do multiple replicas converge?

Key points to discuss:

  • Operational transforms (OT) or CRDTs to merge concurrent edits.
  • Eventual consistency across collaborators, with convergence guarantees.
  • Conflict resolution strategy and why strong consistency would hurt latency.
  • Tie back to weak/eventual consistency being appropriate for real-time editing.
flowchart LR
    A[User A edit] --> S[Sync server]
    B[User B edit] --> S
    S -->|OT / CRDT merge| D[Converged document]
    D --> A
    D --> B

Further reading