This is the behavioural part of a senior SRE loop at a professional social network with hundreds of millions of members, where launches are tied to marketing dates and product teams own their roadmaps. The interviewer wants one real story, told in detail, and will probe how you used data, how you handled the relationship, and what you'd do differently. The general how-to of pushing back is covered by a sister question; this one is about your story.
The interviewer asks“Tell me about a specific time you pushed back on a product launch because you thought it wasn't reliable enough. What did you see, what did you do, and how did it turn out?”
I'd tell the story of a live-event reminder feature that was going to send push notifications to millions of members within a minute, six days before a keynote launch. I ran a fan-out load test that showed a shared settings service collapsing at about 3,800 requests per second, against a projected 6,500, and that service had only 18 percent of its error budget left, so the blast radius was all of messaging and feed, not just the feature. I took it to the PM one-to-one with an alternative: keep the keynote date, but launch to 10 percent of creators with a rate-limited fan-out, a cache and a kill switch. We launched on the date, found a hot-key problem at 25 percent, and reached 100 percent nine days later with no incidents. The lesson I took was that I was involved too late, so we moved capacity review for fan-out features into design review.
A free account unlocks the rest of it, and saves your progress across every track.