Retries That Took Down the DatabasePipeline · easy · ~10 minA backfill kicked off 200 parallel load_dim task instances that each write to the shared Postgres warehouse. The warehouse had a brief 30-second blip. Instead of recovering, everything got *worse*: the database is now pinned at max connections, tasks are failing en masse, and even unrelated pipelines can't reach the DB.The blip is long over. Something about how the tasks retry turned a 30-second hiccup into an ongoing outage. Find it.Evidence

Metrics

Task Logs

Task Config

Checkpoints

Why did a 30-second DB blip turn into an ongoing outage?

Which change best breaks the storm?

Explain why fixed-delay retries at high concurrency are dangerous, and what jitter and a pool each contribute. (interview-style)