Learn the system design
Understand the cache in the order you will use and operate it.
If you have not run a cache yet, start with the quickstart. This reading path explains the decisions behind it. You can stop after the first three pages and return to the rest when your application needs them.
Understand the read and write path
Follow one request
Read the walkthrough. Follow a cold key into L1 and L2, see how peers receive its value, and invalidate it after a database update.
Choose what to keep close and what to share
Read layers. L1 avoids a network hop but belongs to one process. Redis L2 shares values between instances. TTLs and memory limits decide how long each layer retains them.
Keep cached data fresh enough
Read invalidation. Commit writes before invalidating, choose keys you can invalidate precisely, and account for delayed or missed events.
Answer the next operational question
| Question | Read | What you will learn |
|---|---|---|
| What happens when many callers miss at once? | Stampede protection | Local in-flight dedupe, Redis leases, and contention deadlines |
| What if Redis or the origin is unavailable? | Failure handling | Fail-open paths, stale fallback, and errors callers still need to handle |
| How much memory can the cache retain? | Production setup | Entry limits, shared byte budgets, and pressure-aware admission |
| Can a late event overwrite a newer value? | Event ordering | Generation checks, duplicate filtering, and their limits |
| Which event bus fits my deployment? | Event buses | Live delivery, durable subscriptions, and reconnect behavior |
| Which encoding should I use? | Serialization | Encoded L1 values, compression costs, and per-layer codecs |
| How do I see what is happening? | Observability | The dashboard, metrics, and event stream |
Keep cache coordination and business operations separate
getOrSet loaders should read data. A Redis cache lease reduces duplicate work, but failures, expiry, and retries mean it does not provide exactly-once execution.
For durable operation coordination, use the transaction API. It coordinates attempts through one Redis authority. Your database constraints, stable provider idempotency key, and recovery logic remain responsible for the business result.
Where to next
- Walkthrough starts with one concrete request.
- API reference answers method and return-value questions.
- Configuration reference lists options when you are ready to tune.