By default, the OperationFutures return when Couchbase Server has accepted the command and stored it in memory (disk persistence and replication is handled asynchronously by the cluster). That's one of the reason why it's so fast. For most use-cases, that's the behavior that you need. Sometimes though, you want to trade in performance for data-safety and wait until the document has been saved to disk and/or replicated to other hosts.

The Java SDK provides overloaded commands for all necessary operations (that is set(), add(), replace(), cas() and delete()). They all accept a combindation of PersistTo and ReplicateTo enums, which define on how many other servers you want it to persist/replicate. Here is an example on how to make sure that the document has been persisted on its master node, but also replicated to at least one of its replicas.

OperationFuture<Boolean> oper = client.set(
  "important",
  0,
  "document",
  PersistTo.MASTER,
  ReplicateTo.ONE
);
Boolean success = oper.get();
if(success == false) {
  System.err.println(oper.getStatus().getMessage());
}

It is very important to understand that the persistence checks are separate from the actual operation. This means that when the OperationFuture returns false, it can be the case that the operation itself succeeded. It is up to the application layer to determine what went wrong and what to do afterwards. This may seem problematic at first, but imagine the following scenario: because of a power outage in the datacenter, the nodes with the replica copies for the key went down. Now the persistence constraint will fail temporarily, but you can still serve your application because the main node is still available. If you need different behavior, you can add a "rollback" wrapper around it and delete the saved document if persistence problems arise.