Consider the scenario of a Twitter user making a new tweet. In a leader-based replication scenario, the tweet goes to the leader to be committed to the underlying data store. If the user refreshes his timeline, it is possible that the read request may go to a follower that is behind the leader and may not return the latest tweet of the user. The user may erroneously believe that his tweet has been lost. For such scenarios, we want read-after-write consistency or read your own writes. This is a guarantee that a user is always able to immediately read the writes she has submitted or in case of our Twitter user, she sees her tweet on her timeline immediately after submitting it and forcing a browser refresh. Note that the read-after-write consistency doesn’t imply that a different user is able to see the writes made by the first user, since the reads for the other user may be routed to a read replica which is behind the leader. However, eventually all users see the writes made by each other because of eventual consistency.

An example of a read-after-write consistency exhibited in a hypothetical tweet made by a user

widget

Leader replicates to one of the followers but not both

widget

Tweet is replicated at the leader and one of the followers. The Twitter user’s read request unfortunately is routed to a replica that still doesn’t have the latest tweet from the user

widget

The refreshed timeline of the user doesn’t display the latest tweet, violating read-after-write consistency.