* The client-facing API is strongly consistent, and exposes an atomic check-and-set operation.
** This rules out a raft of makes an eventually-consistent datastores that might otherwise work very nicelyNoSQL store rather less attractive.
== Implications for the Client ==
Using a single master for each shard means we don't have to worry about conflicts or consistency. The sharding means this should not be a bottle-neck, and the use of an intermediate router process means we can fail over fast if the master goes down.
'''However''', since we're doing asynchronous replication, there's a chance that recent database writes could be lost in the event of failure. The client will see a consistent, but out-of-date view of its data. It must be able to recover from such a situation, although we hope this would be a very rare occurrence! '''TODO:''' In the presence of multiple clients and asynchronous replication and failover, are we exposing any stronger guarantees to the client than we'd get from an eventually-consistent store? E.g. client A writes, the write is lost due to failover, client B writes, client A is now in an inconsistent state. Is this any different to client A and client B doing a conflicting writes in a NoSQL store, and us arbitrarily picking a winner?
