Couchbase · Use case
Session store: keeping logins alive at peak traffic, and where Couchbase fits
A session store is the database that holds what an application remembers about a signed-in user between requests: who they are, when they last acted, what is in their basket. At peak, when a banking app, a government portal or an online shop serves many times its usual traffic, the session store decides whether users stay signed in or are sent back to the login page. This guide explains the options, the design decisions and where Couchbase fits, and where it does not.
Published 9 min read
In short, for executives
- The problem: modern applications run on several servers. If login state sits in one server's memory, a restart or a busy load balancer signs users out.
- The fix: a shared session store that every server reads, which keeps sessions alive through restarts and spreads the load at peak.
- What to decide: how long a session lives, how it is ended at logout, what happens when a server fails, and where the data sits, since sessions hold personal data.
- Where Couchbase fits: high-traffic channels that need expiry, replicas and the option to query sessions, in your data centre or in Couchbase Capella in Saudi Arabia.
- Where it does not: a small application on one server, or one that already runs a session store that meets its peak.
At a glance
| Question | Short answer |
|---|---|
| What it holds | One small record per signed-in user or device: identity, roles, last activity, temporary state |
| How it is read | By session ID, on almost every request, so speed at peak matters more than anything else |
| How long data lives | Minutes to hours; each record removes itself after an idle or absolute timeout |
| What a failure costs | Usually a forced sign-in, sometimes a lost basket or an interrupted transaction |
| Where Couchbase fits | A shared store with expiry, replicas and queries, self-managed or on Capella |
| From Interkey | Design review, sizing, build, load test and support from Riyadh |
What a session store is, and the problem it solves
HTTP forgets the user after every request. To keep someone signed in, the application gives the browser or mobile app a session ID, usually in a cookie or a header, and keeps the matching record on the server side. On each request the application looks up that record to learn who is calling and what they may do.
With one server, the record can sit in that server's memory. Real channels do not run on one server. A load balancer spreads traffic over several, servers are restarted for patches, and containers come and go as the platform scales. Every one of those events can lose a session held in local memory, and the user sees it as being signed out in the middle of a payment or a form.
Read more
A shared session store moves the records out of the application servers into a database that all of them read. Any server can then answer any request, a restarted server loses nothing, and the platform can add servers at peak without moving users around. The trade-off is that the session store is now on the path of almost every request: if it is slow, the whole channel is slow.
Why session stores matter for Saudi banking apps, portals and online shops
Traffic in the Kingdom often arrives in sharp peaks. Banking apps see them around salary days and during the evenings of Ramadan; government portals during registration windows and deadlines; online shops during seasonal sales and before Eid. These are the moments when most users are signed in at once, and the moments when being signed out costs most.
Sessions also carry personal data, often a national ID or a mobile number beside the session ID. Where they are stored is a data residency question under the Personal Data Protection Law, overseen by SDAIA, and the controls your organisation applies from the National Cybersecurity Authority. Banks also follow their regulator's own requirements.
Where session state can live: the options and their trade-offs
There is no single right answer. Many organisations use two of these together, for example a short signed token for identity and a shared store for everything that changes.
| Option | How it works | Suits | Watch for |
|---|---|---|---|
| Memory of each application server | The load balancer sends a user back to the same server ("sticky" sessions) | Small applications on one or two servers | Sessions lost on every restart or scale-down; uneven load at peak |
| Signed token held by the client | The session data travels in a signed token; the server stores nothing | Identity and roles that rarely change | Hard to revoke before it expires; tokens grow as data is added |
| A table in the relational database | Sessions are rows in the main database | Moderate traffic where the database has headroom | Every request becomes a database write; expired rows need a clean-up job |
| A separate memory-only cache | A cache beside the database holds the sessions | Fast reads where losing sessions on a restart is acceptable | Another system to run; a restart can sign everyone out |
| A distributed NoSQL database with memory and disk | Sessions are documents held in memory, written to disk and copied to other nodes | High-traffic channels that need sessions to survive failures | A distributed cluster to size and operate |
Session store design checklist
These are the decisions we go through with a team before choosing a product. The starting points are common practice; your security policy and your regulator decide the final values.
| Decision | Question to answer | Common starting point |
|---|---|---|
| Session ID | Can an attacker guess or reuse it? | Long random IDs from a secure generator, new ID after sign-in |
| Contents | What really needs to be in the session? | Identity, roles and pointers; no card data, no full documents |
| Idle timeout | How long may a user be inactive? | Short for banking, longer for shopping; set by your security policy |
| Absolute timeout | How long may a session last, active or not? | A fixed limit stored in the session and checked on each request |
| Logout and revocation | Can every session of one user be ended at once? | Delete on logout; a way to find a user's sessions |
| Failure | What does a user see if a store node fails? | Replicas on other nodes, tested with a failover drill |
| Second site | Must sessions survive the loss of a data centre? | Replication to a recovery site, or accept a fresh sign-in |
| Residency and access | Where does the data sit, and who can read it? | In the Kingdom where required; encrypted connections; audited admin access |
How a session store on Couchbase works
On Couchbase, each session is a small JSON document whose key is the session ID, kept in its own collection. Reads and writes go to the Data Service by key, the key-value path our key-value store page describes, so the session lookup on every request does not wait for a query.
Idle timeout without a clean-up job. Couchbase lets you set a maximum time-to-live (maxTTL) on a collection. By default it is reapplied every time a document is created or changed, so each update to a session extends its life, which is the behaviour of an idle timeout. Couchbase's own documentation uses user sessions as the example. A read that should also extend the session can use the SDK's touch operation. Our distributed cache page explains when expired documents are actually removed.
Read more
Absolute timeout and logout. Expiry handles inactivity; a hard limit is a timestamp in the document that the application checks. Logout deletes the document. Because sessions are JSON, an index and a SQL++ query can find every session of one user, so "sign this customer out everywhere" is one query, not a scan.
Persistent or memory only. A Couchbase bucket keeps sessions in memory and on disk, with replicas on other nodes, so a restart does not sign users out. Where losing sessions is acceptable, an Ephemeral bucket (Memory Only in Capella) holds them in RAM only. Regular writes suit most sessions; Couchbase itself advises that durable writes should not be the default. For a second site, Cross Data Center Replication copies sessions to the recovery cluster.
Where a NoSQL session store on Couchbase fits, and where it does not
It fits when a channel has many signed-in users at peak, runs on several servers or containers, and needs sessions to survive a restart or a failed node. It fits well where Couchbase already holds other data for the same channel, such as profiles or a product catalogue, so one cluster serves both.
Read more
It does not fit when the application runs on one server with modest traffic, where local sessions or a database table are simpler. It is not needed when a session store you already run meets your peak and your team knows it well. And it is the wrong choice when nobody, in-house or contracted, will operate a distributed cluster. Our NoSQL database guide covers the wider choice.
Relatedproduct catalogue
How Interkey helps in Saudi Arabia
Interkey is a Couchbase technology partner and sells Couchbase Capella. Self-managed Couchbase Server runs in your own data centre in the Kingdom; as of November 2026, Capella's published regions include Google Cloud's Dammam region (me-central2), and our Capella or self-managed comparison sets out regions and billing. Our engineers work from Riyadh, in Arabic and English, and support the cluster after go-live: timeouts, indexes, failover and upgrades. Remote access for support follows terms your security team sets.
How a session store project runs
-
Review.
Peak signed-in users and requests, session contents, timeouts, failure tolerance and the residency rule. Keeping the store you have is a possible outcome.
-
Design.
Keys, collections, maxTTL, the absolute limit, the logout and revocation path, and persistent or memory-only buckets.
-
Size and quote.
Nodes, memory and replicas on Couchbase Server or Capella, with our work on separate lines.
-
Build and test.
The cluster, security settings and monitoring, then a load test at your expected peak and a failover drill.
-
Switch over.
New sessions go to the new store while old ones expire where they are, so nobody is signed out.
-
Support.
Support from Riyadh after go-live, and training for your team.
Questions buyers ask
What is a session store in a web application?
It is the shared database that holds the server-side record for each signed-in user: identity, roles, last activity and temporary state. Every application server reads it by session ID, so any server can answer any request and a restart does not sign users out.
Should we keep sessions in signed tokens or in a server-side store?
Signed tokens suit identity data that rarely changes, and the server stores nothing. They are hard to revoke before they expire, though. A server-side store lets you end a session at once, at logout or after a security event. Many channels use a short token plus a shared store.
How does Couchbase expire idle sessions?
Set a maximum time-to-live on the collection that holds sessions. By default Couchbase reapplies it each time a session document changes, so active sessions stay and idle ones expire. A read can extend a session with the SDK's touch operation. An absolute limit is a timestamp the application checks.
Can a session store for a Saudi banking app keep its data inside the Kingdom?
Yes. Couchbase Server can run in your own data centre in Saudi Arabia, and as of November 2026 Couchbase Capella's published regions include Google Cloud's Dammam region. Check where backups, logs and support access go as well, since sessions hold personal data.
What drives the cost of a Couchbase session store?
The number of sessions held in memory at peak, their size, the replicas and whether a recovery site is needed. Those set the node count. Capella is billed per node per hour; self-managed Couchbase Server is a subscription by production node. Interkey's work is quoted on separate lines.
How long does it take to move sessions to a new store without signing users out?
It depends on how many applications read sessions, how they are coded today and your security review. Because sessions expire on their own, new ones can go to the new store while old ones run out, so no one is signed out. We estimate the duration after the review.
Next
Read next
Next step
Review your session store design with Interkey
Tell us about the channel (banking app, portal or online shop), roughly how many users are signed in at peak, your timeouts, and whether the data must stay in the Kingdom. We will reply with a first view of the options and what a sizing would cover.
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