# Design a multi-region disaster recovery platform: system design interview question

> Regional recovery under time and data-loss objectives, with strict writer safety, shared dependencies, and uncertain cloud actions.

Source: https://sysround.com/questions/design-multi-region-disaster-recovery-platform
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a platform that coordinates application recovery when a cloud region becomes unavailable. Aim to meet recovery-time and data-loss objectives, but prevent conflicting writers even when safety requires an objective breach."

## What to clarify first

- Scale and regions
- Recovery groups and dependencies
- Platform traffic
- Recovery objectives
- Latency and the recovery clock
- Consistency and availability
- Application and data support
- Recovery readiness
- Control durability and requests
- Scope limits

## Scope of a strong answer

Core requirements:

- Register recovery plans, dependencies, and application objectives.
- Detect regional failures and accept operator recovery requests.
- Coordinate recovery against the time and data-loss objectives.
- Prevent conflicting writers, even when recovery must stop.

Usually out of scope:

- Build database replication or backup storage.
- Recover from a cloud-wide failure.
- Automatically return applications to the original region.

## What interviewers probe

### Active deployments

A region can lose contact with the platform while its applications still serve clients. A second deployment can then create conflicting writes.

### Recoverable data

A healthy replica can lack acknowledged writes. Stale progress reports can hide data loss beyond the application objective.

### Recovery actions

Cloud actions can complete after a timeout. A worker failure can leave the platform uncertain about which actions already changed the environment.

### Recovery deadlines

A critical application can depend on slower services. Detection, data recovery, and client access all consume its five-minute recovery budget.

## Common mistakes

- Treats a network partition as proof that the old application stopped.
- Uses route changes as the only protection against conflicting writes.
- Promises zero loss without a matching data service guarantee.
- Measures RTO from the recovery request instead of the regional failure.
- Retries cloud actions without durable intent or stable request identifiers.
- Accepts a critical plan without timing every transitive dependency against its five-minute deadline.

## The bar by level

- **Senior:** Provides a concrete exclusion method and states its required capabilities. Handles uncertain cloud actions with durable retries. Validates RPO evidence and full-path recovery deadlines.
- **Staff+:** Proves exclusion under partitions and stale commands across all write paths. Resolves authority for shared resources across groups. Validates dependency contracts and capacity at plan admission. Defines behavior under authority loss and uses drill evidence to justify each objective.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=cloud-disaster-recovery


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.