How do you design an LRU cache with O(1) get and put?

Question

Accepted Answer

An **LRU (Least Recently Used) cache** evicts the item that hasn't been accessed for the longest time when it hits capacity. The classic design combines a **hash map** (O(1) lookup) with a **doubly linked list** (O(1) reordering), giving **O(1) get and put**. ## The two-structure design ```text HashMap: key -> node DLL (recency order): MRU <-> ... <-> LRU get/put: map finds node move touched node to front (MRU) in O(1); DLL splices it evict the tail (LRU) when full to the front in O(1) ``` ## Code ```python from collections import OrderedDict class LRUCache: def __init__(self, capacity): self.cap = capacity self.cache = OrderedDict() # preserves access order def get(self, key): # O(1) if key not in self.cache: return -1 self.cache.move_to_end(key) # mark as most recently used return self.cache[key] def put(self, key, value): # O(1) if key in self.cache: self.cache.move_to_end(key) self.cache[key] = value if len(self.cache) > self.cap: self.cache.popitem(last=False) # evict least recently used ``` `OrderedDict` is itself a hash map plus a doubly linked list, exactly the structure described above. | Operation | Time | |---|---| | get | O(1) | | put | O(1) | | space | O(capacity) | ## Why the doubly linked list A doubly linked list lets you **detach a node from the middle in O(1)** (you hold its `prev`/`next`), which is impossible with a singly linked list or array without an O(n) shift. ## Why it matters LRU caches sit in front of databases, web servers, and CPUs to keep hot data fast and memory bounded. This problem is a staple senior interview because it tests combining two structures so that *each other's weakness is covered* — a key system-design skill.