A professional social network's messaging service has an availability SLO of 99.9 percent of requests over a rolling 28 days, about 3 billion requests per window. In the trailing 28 days it has spent 77 percent of its error budget: 18 minutes-equivalent from a bad config push 20 days ago, 8 from a slow dependency (the graph service), and the rest from background errors. Next week product wants to launch a redesigned inbox, and the platform team has scheduled the move to a new Kafka cluster, which they estimate will cost 3 to 5 minutes of errors.
The interviewer asks“Messaging has used most of its error budget for the window. Product wants to launch the redesigned inbox next week, and the infrastructure team wants to migrate messaging to a new Kafka cluster. How do you decide what goes ahead, what waits, and whether we freeze releases?”
I don't decide it in the meeting. I apply an error budget policy that product and engineering leadership agreed in advance. 99.9 percent over 28 days is 40.3 minutes, so 77 percent spent leaves about 9.3 minutes, which puts messaging in our 'restricted' tier: no planned risk-spending, features only behind a flag at small exposure, reliability and security work unrestricted. The 18-minute incident rolls out of the window in 8 days, so I'd move the Kafka migration two weeks out, let the inbox go dark-launched to employees and 1 percent with a kill switch, and ramp it once we're back above 50 percent. Meanwhile, the freed-up time goes on fixing the config push path that burned the budget.
A free account unlocks the rest of it, and saves your progress across every track.