Interactive systems lab / 02
Cache Correctness Lab.
Two instances, many permissions, several ways to cache. Revoke access by hand, then turn on traffic to see the tradeoff over time.
One permission. Two instances.
First move: Run “Stale local grant.” Compare the database permission with both responses, then try “Invalidate on write.”
Choose a strategy
Each instance keeps its own copy. A write on one instance cannot clear the other copy.
Request trace
- Access allowed in the database. Read through A or B to warm the cache.
A cache may speed up an access check, but durable policy remains authoritative. A TTL bounds staleness; write-time invalidation prevents it after a successful change. TTL changes apply to future cache fills. Real systems also need failure handling and cross-instance invalidation guarantees.
02 / Continuous traffic
Now turn on the load.
Simulate 24 independent permission keys. Watch hits, misses, database work, stale responses, and hot keys evolve second by second.
Workload controls
Strategy, capacity, and eviction changes reset the run. Other controls affect the next simulated second.
Every knob changes the flow.
Access by key · last 5s
Key 01 gets the extra hot-key share. The rest use a repeatable pseudo-random distribution.
Cache contents
0 / 8 entries · 0 evictions
| Key | Cache | Value | TTL |
|---|---|---|---|
| No cached entries yet. | |||
The cache is serving current decisions. Change write rate, TTL, or skew to look for the next failure mode.
Reads and writes are discrete one-second batches. Writes happen before reads in each tick. Cache entries are filled sequentially, so this model does not simulate simultaneous miss stampedes or network latency. Rates and capacities describe synthetic operations, not production benchmarks.
Under the model
Fast answers still need truth.
The manual trace follows one permission across two instances. Continuous mode sends synthetic reads and writes across 24 keys. A TTL limits staleness; invalidation removes a shared decision at write time. Capacity and hot-key skew determine how often the database must refill the cache.
Writes happen before reads in each simulated second. The model does not represent concurrent miss stampedes, network latency, or cache failures. A production access check still needs a defined failure policy.
- Warm both local caches, revoke access, then read again.
- Run a write storm under shared TTL, then switch to invalidation.
- Shrink cache capacity and compare database operations.
Lesson 02 / Check your understanding
Can you explain the result?
Which setup prevents a revoked permission from being served after a successful write?