Production / Application cache

Caching Strategies

Cache memory results only where you can define the key, the staleness, and the invalidation. A fast wrong answer is worse than a miss.

Key safety

Compose a key that cannot leak

Memory results are user-specific. Every authorization and retrieval dimension has to be part of the key, or the cache becomes a way to serve one user’s context to another.

EnvironmentrequiredIf omitted: Test and production results merge.
Project IDrequiredIf omitted: One project can serve another project’s memory.
End-user IDrequiredIf omitted: One user can receive another user’s memory.
Normalized queryrequiredIf omitted: Unrelated questions collide on one entry.
Filters and limitIf omitted: A filtered request can serve unfiltered results.

Resulting key

memory-query:v1:sha256({env} + {project} + {query})

Unsafe. Missing End-user ID. This key can return data from the wrong scope.

Freshness

Choose freshness per data type

Seconds: Anything a user can change and immediately expect to see reflected.
Minutes: Read-heavy lookups where a small delay is invisible to the product.
Event-driven: Entries tied to a specific memory: evict on your successful write or delete instead of waiting for expiry.

Before you add it

Do not cache until these hold

You measured a repeated query shape that actually recurs in production traffic.
You can evict on write and delete, and you have a test proving it.
Product owners accepted the staleness window in writing.
Cached values are classified — sensitive content is excluded or encrypted at rest.

Was this page helpful?

← Previous

Horizontal Scaling

Worker Tuning