Greetings amj,
Aurora has many operational modes, and adding on the choice of storage engines, the situation becomes more complicated. You are right to point out that, unfortunately, the documentation of Aurora does not properly claim what data models can be achieved with what configurations, leaving everyone to interpret different statements differently (as in the stack overflow thread you mentioned).
In your setup, if a client writes something and its success is acknowledged by the system, and after that, some other client does the read on the mutated data item and gets a stale value (at least for some time), then the consistency model cannot be linearizable (strong consistency).
With replicas in the availability zones of a single region, the storage layer of Aurora is shared, and in managed service mode, all reads funnel through a front-end service that re-routes the request to the most up-to-date replica. In such a scenario:
(1) No client should see stale reads once a write has been acknowledged as a success by the writer client.
(2) The total order of mutations should be the same on all replicas.
Though it is not clear if the above two hold when replicas are in different AWS regions, but it looks like it is not always the case, as you mentioned.
Thank you for pointing out your operational experience with us and in the light of this discussion it is best to replace this example with Google’s Spanner (that at least claims to provide linearizability for some of its operations).
