Midnight cron stampede
Every day at exactly midnight UTC, your shared Postgres and internal config service get hammered for ~90 seconds: CPU spikes, latency for unrelated online traffic degrades, and you see a burst of identical queries. It turns out hundreds of services each run a `0 0 * * *` cron that refreshes a cached config blob and recomputes daily aggregates at exactly 00:00:00. The fleet has grown, so the midnight spike now causes real customer-facing latency. How do you triage and flatten the spike?
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.