♻ LRU Cache Visualizer — get, put, recency reorder and eviction, live

An interactive, single-file least-recently-used cache that runs entirely in your browser — no backend, no build step.

▶ Live: https://dev48v.github.io/lru-cache/

LRU cache (LeetCode #146) is a rite-of-passage interview question, and the thing that trips people up is that recency of use, not insertion order, decides who gets evicted. This makes that visible.

The rule

A fixed-capacity cache. Every get or put marks an entry most-recently-used and slides it to the front. When a put overflows the capacity, the entry that has drifted to the back — the least-recently-used — is evicted.

What it shows

• Entries laid out front-to-back, MRU on the left, LRU on the right.
• get(key) → HIT moves the entry to the front; MISS if it's not there.
• put(key, value) → adds to the front (or updates + moves up); if that overflows capacity, the LRU entry animates out.
• Live hits / misses / hit rate / evictions.

Try it

1. run sequence — fills the cache, re-gets an early key to rescue it, then keeps putting until it overflows and evicts the key that sat untouched longest. Note the later get(B) misses — proof B was evicted.
2. Manually: at capacity 4, put A, B, C, D, then get(A) (A jumps to front), then put(E) → B is evicted, not A, because A was just used.

Why it's O(1)

A real LRU cache pairs two structures:

• a hash map for O(1) key lookup, and
• a doubly-linked list ordered by recency, so moving an entry to the front and evicting the tail are both O(1) pointer swaps.

This demo uses a JavaScript Map — which preserves insertion order — and re-inserts an entry on each access to move it to the most-recently-used end. Same behavior; the linked list is what makes it O(1) in a real implementation instead of O(n).

Run locally

It's one file. Open index.html, or:

python -m http.server 8000   # then visit http://localhost:8000

License

MIT © 2026 dev48v — dev48v.infy.uk