Same response as Skellla regarding latency across AZ (in EU at least).
We have had a 3 nodes couchbase cluster with all nodes running in a different AZ (eu 1a-1b-1c) during 3 months and had no problem regarding performance or stability.
This cluster was made of 4 buckets with a few million items;
Each bucket had 1 replica configured, and we had an average 400 Ops on couchbase with peaks up to 5K/Sec.
We had a ~50%/50% get/set rate and the stats we had regarding vb_active_num and vb_replica_num were always giving the same number of items for both of them.
Our application/service could afford this ~500µs latency overhead and we were really happy and confortable with splitting couchbase nodes and application servers across AZ (ELB splitting the http traffic across all appNodes/AZ).
Xavier
PS : We are still very happy with the flexibility/agility AWS provides and all the brilliant solutions they have, but after we could have some insight about the traffic we would have to handle, the ratio memory/cost on EC2 made us bought some cheap servers full of RAM and find a more standard housing provider.
– Edit : couchbase is “eventually persisted” regarding persistence from memory to disk an from active vBuckets to replica vBuckets.
The way we consider this is : “don’t use couchbase” if you can’t lose any bit of data in any given situation (server crash, power outage, network failure, etc …), because couchbase would have acknowledged the write to your app as soon as it hits the memory and before it is persisted to disk or replicated to an other node
If adding ~500µs to the “eventually persisted” replica is not acceptable, may be couchbase is not a good fit