™2 min read
What is safe to cache
Every read on the public ring is cacheable because none of it is per-user. The rule of thumb:
- Loyalty tiers and Slice billers — cache for around five minutes; the config rarely changes and each response carries a
generatedUTC timestamp you can use as the cache key’s freshness dimension. - CMS pages — cache keyed on the page key and its
updatedfield; invalidate whenupdatedmoves. - Widget script and stylesheet — static assets; cache aggressively at the CDN and browser.
What not to cache
Do not cache POST responses — enquiries, consent and support-chat replies are one-shot writes and reads-with-side-effects, not cacheable resources. And never cache across users where a response might vary (there are none like that on the public ring today, but keep the habit).
A practical setup
Put a shared cache (a CDN or a small server-side cache) in front of the GET endpoints with a short TTL. Serve stale-while-revalidate if your cache supports it, so a user never waits on a refresh. Because there is no PII, a public shared cache is fine — you are not risking cross-user leakage.
Frequently asked questions
How long should I cache the loyalty tiers?
Around five minutes is a good default. The tier config changes rarely, so a short cache cuts load dramatically and the risk of showing a slightly stale ladder is negligible.
Can I cache responses in a shared/public cache?
Yes for the GET endpoints — they carry no PII, so cross-user caching is safe. Do not cache the POST endpoints.
How do I know when a cached value is stale?
Use the generated timestamp (loyalty, billers) or the updated field (CMS pages) as your freshness signal, and invalidate when it moves.
Funding for UK limited companies
Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.