Scalable Human Blog

Reading after write consistency… aka (read your writes consistency)

What does this mean?

• Guarantees when a user reloads a page they can see any updates they done themselves
  • Although makes no promises about other users
• Other user updates maybe available at some other later time
• This is achieved reassuring the user that there input has been inserted in correctly

How do we implement read after write consistency?

There are numerous number of techniques, here are a few:

Example 1

• When a user is reading something, it may have modified and read it from the leader
• Otherwise they have read it from a follower…
  • This way you know if something may have been modified without querying it 🤔

Example, social media website…

• 👉 The user of the profile is only able to edit there profile
• 👉 Thus a simple rule, the user should always read there profile from the leader and any other user profiles from a follower

⚠️ If most things are editable by the users this is not an affective approach! 👎

• As most things are read by the leader node, therefore negating the benefits of read scaling 👎

Example 2

In the case above an alternative maybe used to decided a read from a leader.

• For example, you can track the time of the last update and for one minute after the last update make all reads from the leader
• You can also monitor the Replication Lag on the followers and prevent queries on any follower that is any more than one minute behind the leader ✅

Example 3

Another technique is to have the client remember the timestamp of the most recent write.

• Then the system can ensure the replica serving any reads for that user reflects updates at least until that time stamp ✅
• If a replicas is not sufficiently up to date then either read can be handled by another replica, or query can wait until replica is up to date
• Timestamps can be logical timestamp, something that indicates ordering of writee such as the log sequence number or the actual system clock which means clock synchronisation becomes critical! 🕗

Multi data centre considerations

Keep in mind your replicas are distributed across multiple data centres for geographical proximity to users, or for availability… there is additional complexity! ⚠️

Another complication can occur, when a user is accessing the same service from multiple devices! ⚠️

• For example, a desktop and a mobile
  • If a user enters information on one device, the user should be able to see this on another device 🤷‍♂️
    • In this case there some additional issues to consider
      • ❌ Approaches that require remembering the timestamp of the last users update become more difficult (example 3) ⚠️
      • 👉 Because the code on one device does not know what happened on the other device…
      • 👉 This metadata will need to be centralised
• If replicas are distributed across different data centres
  • This guarantee the connection will be routed to the same data centre
    • Example: a user uses the home broadband connection
      • The other device uses cellular data network, and the device network routes maybe completely different! 🤪

👉If your approach requires reading from the leader you will first need to route all the user devices requests to the same data centre.

📚 Further Reading & Related Topics

If you’re exploring data consistency and read-your-own-writes guarantees in distributed systems, these related articles will provide deeper insights:

• Distributed Data-Intensive Systems: Logical Log Replication – Learn how logical logs help maintain data consistency and ensure recent writes are visible across distributed nodes.

• What Is Leaderless Replication in Distributed Systems? – Explore how leaderless replication affects consistency guarantees, including challenges in ensuring users can always read their own writes.