On Thu, May 21, 2015 at 3:15 PM, Timothy Potter <thelabd...@gmail.com> wrote: > I'm seeing that RTG requests get routed to any active replica of the > shard hosting the doc requested by /get ... I was thinking only the > leader should handle that request since there's a brief window of time > where the latest update may not be on the replica (albeit usually very > brief) and the latest update is definitely on the leader.
There are different levels of "consistency". You are guaranteed that after an update completes, a RTG will retrieve that version of the update (or later). The fact that a replica gets the update after the leader is not material to this guarantee since the update has not yet completed. What can happen is that if you are doing multiple RTG requests, you can see a later version of a document, then see a previous version (because you're hitting different shards). This will only be an issue in certain types of use-cases. Optimistic concurrency, for example, will *not* be bothered by this phenomenon. In the past, we've talked about an option to route search requests to the leader. But really, any type of server affinity would work to ensure a monotonic view of a document's history. Off the top of my head, I'm not really sure what types of apps require it, but I'd be interested in hearing about them. -Yonik
