Caching
Ask the same question twice and watch the second answer arrive in a fraction of the time — then break the cache on purpose.
Redis with dynamic keys, configurable TTLs and dependency-aware invalidation cascades. Real timings, no simulation.
Run it twice. The first answer scans a hundred thousand assets; the second never touches them.
Run the query twice to compare.
Pretend a region's inventory changed. Everything that read that region is now wrong — including the whole-fleet summary, which read every region.
no requests yet
- cache is empty
“Designed a unified Redis caching architecture with configurable TTLs, dynamic cache keys, dependency-aware and event-driven invalidation, and cache warming to reduce redundant database workloads.”Dell Technologies — Internal Full-Stack Platforms
How it works
The query behind this lab is genuinely expensive: it scans a hundred thousand assets and aggregates them. Nothing sleeps to fake a slow database — the milliseconds on the miss bar are the milliseconds it costs.
The cache key carries every input that changes the answer, scope and TTL policy included. Two different questions can never collide on one entry, and changing the policy cannot serve you a value stored under the old one.
Invalidation follows dependencies instead of guessing. Each entry is tagged with what it read; the whole-fleet summary reads every region, so it carries every region's tag. Change one region and both that region's entry and the fleet-wide entry that depended on it are dropped — the panel names the keys it removed rather than claiming it did something.
Warming is the same path run ahead of a visitor, and it only recomputes what is actually missing.
The store is behind an interface with two implementations: Redis over HTTP where it is configured, and an in-process map otherwise. Whichever is live is named in the panel above — on serverless the in-process one is honestly unreliable, since the instance can change under you, and that is precisely why production wants Redis.