The business says it can tolerate losing at most 15 minutes of data. Design the disaster recovery plan.
What they are really testing: They are testing whether you can turn a business sentence into engineering numbers, and whether you know that an untested DR plan is not a plan. The subtext is cost discipline, because anyone can propose active active.
A real interview question
The business says it can tolerate losing at most 15 minutes of data. Design the disaster recovery plan.
What most people say
drag me
“I would replicate everything to a second region and set up automated failover so we can switch over if the primary goes down. Backups would run nightly to be safe.”
Nightly backups directly contradict a 15 minute RPO, which shows the candidate did not do the arithmetic. It also never asks for RTO, never mentions data corruption, and never says whether anyone has ever tested the failover.
The follow-ups they ask next
Finance says the standby region is too expensive. What do you cut?
Cut by tier, not across the board. Show the per tier cost and make the business own which services drop to a 24 hour RPO.
Your replication is healthy but failover still fails. Why?
Usually a dependency that never failed over: identity, secrets, DNS, a queue, or a third party allowlisted to primary region IPs only.
How do you prove the plan works without breaking production?
Start with a tabletop, then fail over a tier three service for real, then a full game day in a low traffic window with a rollback plan.
What the interviewer is listening for
- Immediately asks for RTO because RPO alone does not size the design
- Tiers services instead of giving everything the strictest target
- Designs for data corruption, not only region loss
- Puts a tested game day with a measured recovery time on the calendar
What sinks the answer
- Proposes nightly backups against a 15 minute RPO without noticing the contradiction
- Jumps to active active without pricing it
- Forgets identity, secrets, and DNS in the failover path
- Cannot say when the plan was last actually tested
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I have not owned a DR plan at this scale, but here is how I would reason about it: 15 minutes is the RPO, and I would need the RTO before I can pick a design, because those two numbers decide whether this is a warm standby or an active active setup.”
Keep going with system design
Mid
Design a log and metrics ingestion pipeline for a platform with about 200 services. Engineers need to search logs and alert on metrics.
Mid
Design an image upload and processing service for a marketplace app. Users upload photos from their phone, and we need thumbnails and a moderation check before the listing goes live. Walk me through it.
Senior
Design an event-driven order processing system for an e-commerce site. Payment, inventory, and shipping are separate services.
Senior
Design an analytics pipeline that produces a daily report for the leadership team by 8am. The data comes from a production database and a stream of app events.
Senior
Design a system that must never lose a message. It ingests payment notifications from a partner and each one must be processed exactly once.
Senior
We have about 50 product teams and every one of them has rolled their own pipeline. Design a CI/CD platform that all 50 can use. Take me through it.
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free