Couchbase · Caching
Distributed cache: when a separate cache is enough, and when one platform can do both
A distributed cache keeps frequently used data in memory across several servers, so applications read it quickly and the main database is asked less often. Couchbase can serve as a cache and a database in one platform, with data held in memory and on disk, optional expiry, and replicas on other nodes. Interkey is a Couchbase technology partner and sells Couchbase Capella; we assess the workload first, and sometimes the answer is to keep the cache you have.
Published 5 min read
In short
- What it is: data kept in memory across several servers so reads are fast and the database behind it is spared.
- The usual cost: a cache beside a database means two systems to run, and the risk of stale data when they disagree.
- The Couchbase option: one platform that holds data in memory and on disk, expires data on a timer if you ask, and keeps replicas on other nodes. Memory-only buckets are available where nothing needs to persist.
- Who it is for: portals, catalogues, sessions and profiles under heavy read load.
What a distributed cache is for
A database answers every question from storage. When thousands of users ask for the same product page, the same profile or the same session, most of those answers are repeats. A cache stores the repeats in memory, close to the application, so the database is asked less often and pages load sooner.
A distributed cache spreads that memory across several servers. That matters for two reasons: the cache can grow past one machine, and losing one server does not empty the whole cache.
Read more
The common pattern is cache-aside. The application checks the cache first, reads the database on a miss, and puts the result in the cache. It works, but it brings problems that appear later:
- Stale data. The database changes and the cache still holds the old value. Someone must decide how long that is acceptable and write the code that removes old entries.
- Two systems to run. Each has its own sizing, patching, monitoring and failure behaviour.
- A cold cache. After a restart the cache is empty, and the database takes the full load at the worst moment.
Cache only, or cache plus database: the options compared
| Option | How it works | Think about |
|---|---|---|
| A separate cache beside the database | Memory-only store holds copies; the application manages what goes in and out | Two systems, stale data rules, a cold cache after restart |
| Couchbase with memory and disk | Data lives in memory and on disk in one platform; reads of hot data come from memory | Memory sizing: how much of the working set must stay in RAM |
| Couchbase memory-only buckets | Data is held in RAM only, with no persistence to disk | Data is lost if ejected or if the cluster is lost; writes may be refused when full, depending on the policy you set |
The right choice follows from one question: if this data vanished, could the application rebuild it from somewhere else? If yes, a memory-only bucket may be enough. If no, the data needs to persist.
What Couchbase's documentation says about it
We limit this section to what Couchbase documents:
- Memory and disk. Couchbase buckets store data both in memory and on disk. When a bucket nears its memory quota, the Data Service may eject data from memory; ejecting does not remove the data from disk, so it stays available.
- Memory only. Ephemeral buckets retain data in RAM only. Ejected data is lost. With ejection turned off, a full bucket refuses new writes until memory is freed. Capella calls these Memory Only buckets.
- Expiry. You can set an expiration on a document when you create or change it, or set a default on a bucket or collection. When it expires, Couchbase Server removes it, though not at the exact second: removal happens when the document is accessed, when the expiry pager runs, or during compaction.
- Replicas. Buckets replicate data across a configurable number of servers, and each replica sits on a different node from the original.
- Growth. Once a cluster exists, nodes can be added, and Couchbase redistributes data as the configuration changes.
Read more
Couchbase also publishes performance figures. We do not repeat them here, because the numbers that matter are the ones measured on your data and your hardware. A proof of concept on your workload is the honest way to get them.
When Couchbase as cache and database fits, and when it does not
It usually fits when:
- the same data is read very often and also needs to be stored safely;
- the data is shaped as documents or records looked up by key, such as profiles, sessions and catalogue entries;
- you expect to grow by adding nodes.
It usually does not when:
- a cache you already run meets the need and your team knows it well;
- the core data is strictly relational with multi-entity transactions at its centre, which should be examined carefully before leaving a relational engine;
- there is no team, in-house or contracted, to run a distributed system.
Our SQL or NoSQL guide sets out how to decide for an enterprise workload.
RelatedSQL or NoSQL guide
How Interkey helps in Saudi Arabia
Couchbase is an Interkey technology partner, and the platform is Couchbase's. Interkey sells Couchbase Capella, its managed cloud service. For self-managed Couchbase Server, the vendor subscription is quoted alongside our work. Our Capella page compares the two operating models, including regions near and in the Kingdom.
Work starts with a workload review: which data is read most, how stale it may be, how big the working set is, and where the data may live.
Questions buyers ask
What is a distributed cache?
A cache whose memory is spread across several servers. It holds frequently read data close to the application so the main database is asked less often, and it can grow past one machine.
Can Couchbase replace a separate cache?
For some workloads, yes: it holds data in memory and on disk, supports expiry, and replicates across nodes. Whether it suits yours depends on the data and the load, which a workload review answers.
Is Couchbase data stored only in memory?
Not by default. Couchbase buckets store data in memory and on disk. Memory-only buckets exist for data that does not need to persist.
Can cached data expire automatically?
Yes. You can set an expiration per document, or a default on a bucket or collection. Removal is not instant: it happens on access, when the expiry pager runs, or during compaction.
Do you publish latency numbers?
No. Couchbase publishes its own figures, and the numbers that count are those measured on your data and hardware. We suggest a proof of concept on your workload.
Does Interkey sell Couchbase Capella?
Yes. Interkey sells Couchbase Capella and assesses, models, migrates and operates either Capella or self-managed Couchbase Server.
Next
Related pages
Next step
Review a caching workload
Tell us what the application serves, which data is read most, how stale it may be, and any rule about where the data must stay. We will reply with whether one platform fits and what the first step would be.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia