OrderedDict keeps insertion order AND lets you mutate that order in O(1). move_to_end(key) lifts a key to the back of the dict; popitem(last=False) removes the front item. Together they implement LRU semantics: every get and successful put lifts its key, and any put that pushes past capacity removes the least-recently-touched front entry. Because both operations are O(1), the cache scales: 100K entries with 1M operations stays well under a second.

functools.lru_cache(maxsize=N) is the production answer 95% of the time: thread-safe, written in C, and as fast as you will ever match in pure Python. It memoizes calls keyed by argument values, so the function must take hashable arguments and return values that depend only on its inputs. cache_info() exposes hit / miss counts so you can confirm the cache is actually helping. Reach for the LRUCache class only when you need keys that are not function arguments (HTTP responses by URL, image thumbnails by id), or when you want to expose the cache as a first-class object.

200K mixed get/put operations should complete in well under a second on any modern machine, which is what 'O(1) per op' buys you. If you replace OrderedDict with a plain list and shuffle entries on every access, the same workload becomes O(n) per op and runs orders of magnitude slower. Always benchmark caches against your actual workload distribution: random access, hot-key access, and scan-once-then-discard all stress LRU differently. The right capacity is usually 'hot working set + 20% headroom', and the right metric is hit rate, not ops per second.