30-Second Glance
- Async replication makes reads eventually consistent — a client can read its own write from a lagging replica and not find it.
- Read-your-writes fix: route the read to the same DB, or ask the replica whether it has synced past the write's timestamp before reading.
- Monotonic reads guarantee time never moves backward: versioning/timestamps, client-side caching of the newest seen version, and read repair.
- Consistent prefix reads guarantee order (A, A-B, A-B-C — never A-C): e-commerce updates, social feeds, and collaborative docs depend on it.
- All three are cheaper than full linearizability: less staleness weirdness without paying for total recency.
Making eventual consistency less shit !!
Reading your own writes:
- Let's say I write to the DB and read from the replica, I might get inconsistent result if the data is not propagated to the DBs.
- To solve this
- We can read from the same DB.
- In case we're reading from a replica, we can ask the DB if data from the particular timestamp is synced or not before reading from that replica.
- On the right, Data replication is implemented using Versioning and Timestamps(to know more read below).
Monotonic reads:
Monotonic reads are particularly relevant in distributed systems with data replication, where data is copied and maintained across multiple nodes. Here’s how monotonic reads can be implemented:
-
Versioning and Timestamps: Each data item can be versioned or timestamped. When a process reads a data item, it records the version or timestamp. Subsequent reads ensure they only return the same or newer versions.
-
Client-side Caching: Clients can cache the latest version of data items they have read. Any future read requests first check the cached version to ensure monotonicity.
-
Read Repair Mechanisms: During a read operation, if a node detects that it has an older version of the data item compared to the version the client has already seen, it can initiate a read repair process to fetch and return the latest version from other nodes.
Consistent prefix reads:
Consistent Prefix Reads is a consistency model in distributed databases that ensures all read operations see writes in a sequential order. In other words, if a series of writes (A, B, C) are made to a database, a read will see either A, A-B, or A-B-C, but never A-C or B-C. This model guarantees the order of operations but does not necessarily provide the most recent data immediately.
Use Cases
- E-commerce Applications: Ensuring order consistency in updates like price changes, stock updates, and product descriptions.
- Social Media Platforms: Ensuring posts and comments appear in the correct sequence across different regions.
- Collaborative Tools: Ensuring document edits are seen in the correct order, even if not all edits are immediately visible.
Trade-offs
| Approach | Pros | Cons | Use when |
|---|---|---|---|
| Read from the write's DB | Trivial read-your-writes | Loses replica load-balancing; DB may be far/hot | Session owner's immediate re-read |
| Timestamp check before replica read | Keeps replica reads but only when caught up | Extra version/timestamp bookkeeping and wait | Read-your-writes across replicas |
| Monotonic reads (cache + read repair) | Never see time go backward | Client cache state; repair adds read-path work | Feeds and timelines where regression confuses users |
| Consistent prefix reads | Ordered view of a write sequence even if lagging | Doesn't promise the latest data, only order | Price/stock updates, comment threads, doc edits |
Interview One-Liners
Q: What stale-read anomaly motivates this note? A: Writing to the leader then reading from an uncaught-up replica returns the old value — you can't read your own write.
Q: Two fixes for read-your-writes? A: Read from the same DB you wrote to, or check the replica has synced past the write's timestamp before reading.
Q: How do you implement monotonic reads? A: Version/timestamp every item, have the client remember the newest seen version, and run read repair when a replica offers something older.
Q: What does consistent prefix reads guarantee? A: For writes A, B, C you may see A, A-B, or A-B-C — but never gaps like A-C — order without recency.
Q: Name the note's use cases for prefix reads. A: E-commerce (price/stock/description order), social media (posts/comments in sequence), collaborative tools (ordered doc edits).