Caching

Hook

A nearby copy saves a trip, but somebody must keep it current and decide when a write is truly safe.

Watch

Choose who owns freshness and durability. Use the validated parameter controls or edit the JSON scenario, then select Load input to recompute the trace.

How it works

Compare cache-aside, write-through and write-back with LRU capacity and TTL. Lose invalidation to expose stale versions, or crash a write-back cache before dirty values flush.

Every visible outcome comes from the displayed state model. Timings, capacities and failures are illustrative assumptions, not cloud benchmarks or production-protocol guarantees.

Try it

Predict the next admission, delivery, cache, ownership or coordination decision. Introduce one failure at a time and account for every accepted, rejected, pending or committed outcome.

Complexity

The player separates operation counters from architectural trade-offs. State size follows the active keys, tasks, nodes or retained history; the references use bounded scenarios. Container choices and presentation scans can affect simulator costs.

Code

The four references implement the core model or its decision round. Queue/inbox and local ledger atomicity are explicit assumptions. Distributed deployment additionally needs durable shared state, complete protocol rules and operational validation. Reference inputs are fully validated/defaulted by the lesson; standalone callers must provide the shown fields.

When to use

Use when a measured reuse pattern justifies a cache and its invalidation, persistence and failure policy are explicit.

Interview pitfalls

A hit rate alone says nothing about freshness or durability. Real write-through partial failures need an additional protocol.

Quiz

Justify the model’s decision and name one production concern outside its scope.