Couchbase Caching Optimization and Case Studies in iQIYI's Bubble Social Backend

iQIYI's social service "Bubble" serves over 60 million daily active users, with peak QPS reaching 80K+. The large data volume and high request rate require a highly reliable, high‑performance, and large‑capacity online cache system.

The article shares practical experience and optimization methods for using caches, focusing on Couchbase (CB) and Redis.

Couchbase Overview

Couchbase was formed in early 2011 by the merger of CouchOne (creator of CouchDB) and Membase (built by the main developers of memcached). Membase provided a scalable key/value store using the memcached wire protocol and SQLite, while CouchDB offered a document database with replication. Couchbase combines the strengths of both.

Couchbase vs Redis

Both are excellent caching products, but each has distinct advantages. Redis supports more data structures, richer application scenarios (queues, pub/sub, leaderboards), server‑side operations, a larger community, and transactions. Couchbase offers larger capacity, a professional management UI, client‑side consistent hashing for higher performance, higher availability when a server fails, and strong scalability.

vBucket in Couchbase

Each bucket is logically divided into 1024 vBuckets. A key is hashed (crc32(key) % 1024) to determine its vBucket, which maps to a specific server node. This design enables high reliability and automatic failover.

Friendly Web Console

Couchbase provides an intuitive web console for monitoring and management, simplifying operations.

Case 1: Like System Cache Optimization

The like system handles two scenarios: feed likes and comment likes. Initial design stored a key per entity (feedId or commentId) with a set of user IDs, leading to low cache hit rate and high HBase pressure. After analysis, the key was changed to uid+entityId with a boolean value indicating whether the user liked the entity. Further optimization introduced a sharding scheme ( entityId+shard ) to balance space and query latency. The final design achieved >99% cache hit rate and stable success rates.

Case 2: Voting System Cache Optimization

The voting system uses a key per option to support atomic INCR operations. During a popular TV show, the system generated up to 1.4 million OPS, causing CPU alarms. The solution introduced an asynchronous task that aggregates counts every few seconds, reducing OPS dramatically.

Case 3: Couchbase SDK Upgrade

Older SDK versions caused timeouts after cluster rebalance and occasional buffer overflow exceptions. Upgrading from SDK 1.4.11 to 2.3.2 required handling API compatibility, ensuring data safety for rollback, and leveraging new features. Different upgrade strategies were applied for two systems based on data types and risk.

Other Considerations

• Hot‑cache migration strategies: gradual worker‑by‑worker switch or bulk MapReduce load. • Cross‑IDC data synchronization: using Couchbase XDCR (recommended) or custom Kafka‑based sync. • Traversing all keys: Couchbase lacks a KEYS * command; a workaround is to sync data to an offline cluster, build a view, and paginate via REST API (requires JSON values). • Development & operations tips: use String for INCR , set TTLs as absolute times for >1 month, adopt the latest client library, monitor ping latency, set alerts early, and keep memory usage below 75‑85% of allocated capacity.

Summary

Effective Couchbase cache optimization relies on deep understanding of business behavior, balancing cache hit rate, OPS, and memory usage, designing appropriate keys, and employing compression techniques when needed.