The Memoization Memory Bomb
#sre-critical — analytics pod OOM killed after 4 hours
SRE: Memory crept to 8GB until Exit 137. Junior dev memoized get_user_analytics() with {} — every request passes unique timestamp_ms. Zero cache hits, infinite dict growth.
The trap: Memoization on high-cardinality keys = unbounded memory allocation.
Your task
Fix `get_user_analytics()` in `analytics_service.py`: FIFO eviction when cache reaches MAX_CACHE_SIZE (1000).
Book: memoize with a dict · Prod: bound the cache or OOM the pod.
Skills you'll prove
Interview Tip
When asked about memoization or caching, say: "Memoization is just caching with a fancy name. The trap is applying it to functions with high-cardinality arguments like timestamps, UUIDs, or pagination cursors — you never get cache hits, only cache misses that grow the dictionary forever. I debugged an analytics service that OOM'd after four hours because someone memoized on timestamp_ms. The fix wasn't removing memoization — it was bounding the cache with FIFO or LRU eviction. In production, every cache needs a max size or TTL. An unbounded cache is a memory leak with extra steps."