For the operations "store/load/delete" and any combination of those using the bulk transaction calls, the effects are atomic immediately visible on a single node. They will always retrieve the latest versions of that information from a single node. We could say that this was ACID but that might annoy some people because in a multi-node set-up it is all eventually consistent.
On top of that, the secondary indexes used for querying are written as background operations meaning a query might not always return the latest results (for example under high write scenarios). They're pretty fast though.
Each document written to a store has a vector clock associated with it, and this is used to track the history of that document. These are surfaced to the HTTP client as Etags and are available otherwise in the "metadata" associated with a document.
Submitting a document with an out of date vector clock, or an unknown lineage will cause a conflict. This can happen under the following circumstances
A good description of vector clocks can be found on Basho's site and for all intents and purposes the use and behaviour of these clocks is identical except
When writing to a server without specifying the Etag, the server will write using the latest version of the vector clock it knows about and thus preserve lineage.
We're going with a CouchDB-ish model where writes are to a single server, and replication will occur eventually. There are plans to allow occasionally connected clients such as Clojurescript enabled browsers to be a part of this model and thus quorum writes wouldn't necessarily provide all that much on top of the experience.
Replication can be any topology of servers pointing to other servers and at present is completely manual. Auto discovery is in the pipeline.
We don't care too much about throughput (although writing slow code should be avoided), what we care about is a good out of the box developer experience and we will be pushing to make the ops experience amazing too. Every question or confused user should be considered a bug.
Craven is still under development, and any documentation should be considered entirely transient. That said - we have tried to make it obvious which APIs are for public consumption and playabouts now by adding docstrings and documentation on this site.