Couchbase SDK and Application Development
The SDK and Application Development domain tests your ability to connect an application to Couchbase, perform CRUD safely, handle concurrency and failures, and use transactions and durability correctly. Questions often present a code scenario or ask which SDK call or error-handling pattern fits.
Connection and object hierarchy
SDK 3.x uses Cluster, Bucket, Scope, and Collection. Connect with a connection string such as couchbases://10.0.0.5 for TLS or couchbase://... for non-TLS, pass credentials, and set timeouts. The default scope is _default and the default collection is _default; production designs should use named collections. Reuse the Cluster object; creating one per request exhausts resources. Close it on shutdown.
CRUD and optimistic concurrency
upsert creates or replaces, insert fails if the key exists, replace fails if it does not, and remove deletes. get returns the document plus its CAS value. To avoid lost updates, read the CAS, modify, then call replace with that CAS. If another writer changed the document, the SDK throws CasMismatchException; retry the read-modify-write loop with a bounded number of attempts. counter is atomic for numeric counters. TTL/expiry and touch manage document lifetime, and sub-document operations mutate fields without fetching the whole document.
Durability, consistency, and transactions
Write durability is set per operation with DurabilityLevel values such as MAJORITY and MAJORITY_AND_PERSIST_TO_ACTIVE; this trades latency for replication safety. Query consistency is separate: use request_plus when a query must see a just-completed write. SDK transactions provide ACID semantics across documents: begin, mutate, commit or rollback. They are not a substitute for good document design under high contention.
Worked example
A balance document is read at CAS 0x1a2b. The application adds 50 to the balance and calls replace with CAS 0x1a2b. A concurrent writer already replaced the document, so the SDK returns CasMismatchException. The correct response is to read again, apply the business rule to the fresh value, and retry with the new CAS, usually up to a small limit. Blindly overwriting without CAS loses the other update; retrying forever can livelock.
Traps
Using insert when you mean upsert causes key-exists failures on retries. Treating CAS as a lock is wrong: it detects changes, it does not block writers. Catching every exception as fatal hides retryable timeouts. Setting very low timeouts causes false failures under load. Forgetting to close clusters leaks connections, and assuming query consistency is automatic leads to stale reads.