Designing Data-Intensive Applications [Book Highlights]

[ Part II : Chapter V ] Distributed Data

Reading Your Own Writes

• Many applications let user submit and view the data immediately such as comment section.
• So if the write goes to the leader and read happens on the follower, there can be mismatch due to eventual consistency. (With asynchronous replication this is a problem)

A user makes a write, followed by a read from a stale replica. To prevent this anomaly, we need read-after-write consistency

• In this situation, we need read-after-write consistency, also known as read-your writes consistency (It makes no promises about other users)
• Probable solutions,
  • When reading something that the user may have modified, read it from the leader; otherwise, read it from a follower.
  • The client can remember the timestamp of its most recent write—then the system can ensure that the replica serving any reads for that user reflects updates at least until that timestamp. If a replica is not sufficiently up to date, either the read can be handled by another replica or the query can wait
• Another complication arises when the same user is accessing your service from multiple devices. here you want to provide cross-device read-after-write consistency

Monotonic Reads

• An anomaly that can occur when reading from asynchronous followers is that it’s possible for a user to see things moving backward in time.
• e.g two queries goes on different replicas and both read async updates the later reads older one. seems like backward travelling.

A user first reads from a fresh replica, then from a stale replica. Time appears to go backward. To prevent this anomaly, we need monotonic reads

• Monotonic reads is a guarantee that this kind of anomaly does not happen. It’s a lesser guarantee than strong consistency, but a stronger guarantee than eventual consistency.
• One way of achieving monotonic reads is to make sure that each user always makes their reads from the same replica
• For example, the replica can be chosen based on a hash of the user ID, rather than randomly.

Consistent Prefix Reads

If some partitions are replicated slower than others, an observer may see the answer before they see the question.

• consistent prefix reads. This guarantee says that if a sequence of writes happens in a certain order, then anyone reading those writes will see them appear in the same order
• but in most of databases databases, different partitions operate independently, so there is no global ordering of writes
• One solution is to make sure that any writes that are causally related to each other are written to the same partition