JavaScript's Map keeps keys in insertion order, and re-setting an existing key does NOT move it to the end (which means we have to delete and re-insert). On get, we delete-and-reinsert to mark the key as recently used. On put, we evict the oldest by reading data.keys().next().value. Both operations are O(1) on a Map, so the cache is O(1) for both get and put. This is the cleanest LRU implementation in modern JavaScript and the version most production code uses.

The classic textbook LRU pairs a hash table (key -> node) with a doubly linked list (recency order). get finds the node via the map, then unlinks and re-inserts at the front in O(1). put either updates an existing node or inserts a new one at the front; when over capacity, the tail node is the LRU eviction. This is the implementation languages without insertion-ordered hashes (Java's HashMap, C++'s unordered_map) need to write by hand. In JavaScript the Map-backed version above is shorter and just as fast, but knowing this version is interview gold.

Real-world caches usually combine 'evict when full' and 'evict when stale'. Storing each entry as { value, expires } lets get lazily evict expired entries on access (no background timers needed). The capacity check still uses LRU eviction for entries that are still fresh. This composition handles the two failure modes most production caches face: 'too many entries' and 'this entry got out of date'. For multi-process caches, swap the Map for Redis with EXPIRE and the same shape works.