Caches
A cache remembers recent search answers. The first time someone runs a query, Search Stack works out the results and keeps a copy for a few minutes; anyone asking the same thing in that window gets the saved answer straight back — like keeping a note of a question you were just asked instead of working it out again. Every list starts on the built-in in-memory cache with nothing to set up, and you can bring your own Redis-compatible service when you want more control.
Auto-plays · use Back / Next to step through at your own pace.
How caching works
Search and suggestion answers are cached per list, keyed by the exact request, and kept for a few minutes — long enough that a burst of people asking the same thing is served instantly, short enough that fresh data shows up quickly. Caching is best-effort by design: if a cache is slow or unreachable, the request simply runs as normal and the answer is computed fresh. A broken cache can never break your search — the worst case is a cache miss.
A search across a group is cached too — the group borrows the cache of its member lists.
The built-in cache
The reserved in-memory service (shown as provider Search Stack on the Caches page) is the zero-setup default: answers are kept in the memory of the server that handled the request. For most accounts this is all you need.
Bring your own cache
- Go to Caches in the top navigation and click Add Cache Service.
- Pick a provider — Redis, Valkey or Azure Managed Cache. Any Redis-compatible service with a publicly reachable address works.
- Give it a name, paste the connection string from your provider, and pick the nearest region so lookups take the shortest route. A
rediss://address switches on an encrypted connection automatically. - Click Create. The connection is tested live before the service is saved — a cache that can’t be reached is never added.
Point a list at it
Once the account has a named cache service, each list can choose it: open the list, then Options → Change Cache Service. The dialog shows the list’s current cache and lets you switch to a named service or back to In-memory (default). The Create List dialog offers the same choice up front. On the Caches page, the Used By count shows how many lists rely on each service — and deleting a service warns you about exactly those lists first.
In-memory or your own?
| In-memory (default) | Your own cache | |
|---|---|---|
| Setup | None | Paste a connection string |
| Where answers live | The memory of the server that answered | One shared service — every server sees the same saved answers |
| Capacity & region | Managed for you | You choose the size, region and provider |
| Cost | Included | Your provider’s bill, under your control |
A worked example
Say your store’s products list goes into a flash sale. At nine o’clock, thousands of shoppers search “air fryer” within the same minute. The first request computes the results; every other shopper in that burst gets the saved answer back in a few milliseconds. With the built-in cache, each Search Stack server keeps its own copy; pointing the list at your own Redis in the same region as your customers gives every server one shared memory — so the very first “air fryer” answer of the morning is also the last one that needs computing.