Timestamps should mostly be supplied by the client. They can be present or in the past, it doesn't matter.
If a write succeeds only partially, it will most likely be replicated up to the other servers (and thus be consistent) by the hinted handoff queue. This should be a fast recovery. Anti-entropy is for some much longer term failure that needs to be resolved.
Our use of hinted handoff and our goals for that are just borrowed ideas from Dynamo (the paper not the AWS DB), Cassandra, and Riak.
The issues around consistency are only for the failure cases. During normal operation you'd see a consistent view (within a second or some small delta).
Mostly the system is AP, with some parts that are CP. But if you really examine it, it's neither pure CP nor pure AP. It's some other thing.
That's fine too. However, queries by default set an end time of "now" on the server. So depending on how far in the future the point is, it may not show up in a query that doesn't have the end time explicitly specified to past the future time of that point.
If a write succeeds only partially, it will most likely be replicated up to the other servers (and thus be consistent) by the hinted handoff queue. This should be a fast recovery. Anti-entropy is for some much longer term failure that needs to be resolved.
Our use of hinted handoff and our goals for that are just borrowed ideas from Dynamo (the paper not the AWS DB), Cassandra, and Riak.
The issues around consistency are only for the failure cases. During normal operation you'd see a consistent view (within a second or some small delta).
Mostly the system is AP, with some parts that are CP. But if you really examine it, it's neither pure CP nor pure AP. It's some other thing.