Implementing 'Write follows Read' guarantee of causal consistency

[Unmesh_Joshi]

Hi,

How is ‘write follows read’ guarantee maintained if a read request from a client goes to a follower server?
Say client’s view of clusterTime is 2, and a particular mongodb server’s clusterTime is 1. If a read request goes to the server with afterClusterTime 2, the server needs to update its clusterTime to make sure any subsequence write requests will happen at later time. To make sure that the clusterTime is updated, the server needs to make sure it ticks the clusterTime by doing a no-op write?
Its easy if the server where the read request is sent is a the primary. But what if the request goes to follower replica?
There are two scenarios here

1. The primary might have already written something at clusterTime 2, and its just that the follower is not yet received the update, so it might just wait.
2. The primary itself has not written anything in a while and its clusterTime is not updated to 2. In this case the follower needs to initiate a no-op write to update the cluster time through the primary…
   Is this how its done in mongodb? Its tricky to figure out when to wait to catchup with all the updates from primary and when to trigger a no-op write. So followers can possibly just handle the read requests well in past and otherwise just redirect the read request to the primary?

Thanks,
Unmesh

[Unmesh_Joshi]

A supplementary question.
I see that mongodb read concern handling does two checks.

1. ClusterTime
   I assume, this is updated on each node through the cluster time gossip. If cluster time is not upto date and less than afterClusterTime value, the server returns an error. So client will need to try another server.
2. OperationsTime
   If clusterTime is up-to-date, the server checks if operationTime is as up-to-date as the afterClusterTime value and if not, will always do a no-op write through the leader. (after a small wait to give a chance for secondaries to receive updates)
   So is it correct to say that read requests with afterClusterTime value greater than latest operation time, will always do a no-op write to push the clustertime and operation time to the value more than the afterClusterTime, and that way provide write follows read guarantee?

[Unmesh_Joshi]

I see this discussion, which is related.

Does query advance Logical Time in MongoDB?

As I went through the MongoDB source code and the paper: Implementation of Cluster-wide Logical Clock and Causal Consistency in MongoDB. I have a question about the clock time: Does MongoDB advance the clock time when sending a query with ClusterTime field. For instance, in Change Streams, MongoS build several cursors to each MongoD, then it will send a getMore query to MongoD, so I want to know whether it’’ advance the HLC. As the above paper said: Cluster nodes (mongod, mongos, config serve…

I think my question in this post is related. And I think the no-op writes which happen as part of read requests, is critical to move the operationTime beyond the the time requested in read?