Pod memory climbs then OOMKilled
A read-heavy catalog service on Kubernetes (limit 2Gi) starts getting OOMKilled (exit 137) a few times a day, always 6–10 hours after a pod starts, never right away. The memory graph climbs a slow staircase and never plateaus, but request rate and latency are normal. Heap/RSS grows roughly in proportion to the number of *distinct* product IDs seen since boot, not to current QPS. A release last week added an in-process `map[string]Product` cache 'to cut DB load' — it had a great hit rate in the demo. There is no eviction configured. Triage and mitigate.
What a strong answer looks like
Stop the bleeding first (mitigate), then form hypotheses from real signals. Separate root cause from symptom, communicate status as you go, and close with what prevents a repeat.
0:00 of about 30 min
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.