We discussed supporting multiple consistency levels per-request in https://github.com/wikimedia/restbase-mod-table-cassandra/pull/133. From the discussion there:

How about letting the request indicate which level of reliability / consistency it needs, and then returning success / error based on that?

Great idea.

There is already some embryonic support for that with the consistency query property in the table storage backend, but so far that's only applied to the C* queries and is not fully specified or robust. As far as I know it is also not used for anything in RESTBase. I guess the main use cases are 'strongly consistent', 'eventually consistent', plus (perhaps?) a 'fire & forget' level.

I wouldn't use consistency though, because we use it in the storage back-end with a meaning not compatible with what we are after here. Both address consistency, but with slightly different targets. How about using dataConsistency ? With the values you suggest:

• strong - do the updates synchronously and return 2xx *iff* both the main and background updates succeed, i.e. return the result returned by the background update
• eventual - do the updates synchronously and return the result of the main update
• loose (or quick or even none) - do the main update synchronously and the background update asynchronously and return the result of the main update

As an additional data point, DynamoDB defaults to eventual consistency for writes. However, their definition is that it's going to happen soon, without further writes.