Design your cache, sessions and queues correctly.
Cache entries, sessions and queued jobs have different durability needs.
What matters for your application
Caching frequently used API responses
Include project and user context in cache keys, and set TTLs.
Backend sessions and short-lived token data
Keep the authoritative data source separate from cache.
Task queues between web services and workers
Evaluate persistence, memory limits and eviction behavior for queues.
Where it fits
Cache entries, sessions and queued jobs have different durability needs. Start Redis or Valkey planning by making that distinction explicit.
- Caching frequently used API responses
- Backend sessions and short-lived token data
- Task queues between web services and workers
Its place in your application
An API may use the cache for frequent reads while a worker consumes queued jobs. Data that can be rebuilt from the main database should not share an eviction policy with work that must survive restarts.
Before you begin
Choose services around the actual needs of your application. Include these points in your development and release plan.
- Include project and user context in cache keys, and set TTLs.
- Keep the authoritative data source separate from cache.
- Evaluate persistence, memory limits and eviction behavior for queues.
Common questions
Does Redis replace my database?
For caching, the relational database remains the authoritative source. Redis / Valkey can provide an access or queue layer. Define durability and loss tolerance for each purpose explicitly.
Can I provision a live resource now?
Not yet. New registration and customer allocation are closed on the live site. Product guides are published; local development simulation does not create real services.