How the interviewer opens it
“Design a service that creates automatic database backups and restores a database to a selected time. The service must limit production overhead and meet recovery-time and data-loss targets.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Database fleet
- Workload and read:write mix
- Recovery history
- Data-loss target
- Recovery-time target
- Production overhead and latency
- Consistency and availability
- Durability and access
- Recovery result
- Exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create automatic backups with low production overhead
- Restore a separate database cluster to a selected time
- Report available recovery intervals and target breaches
- Test that restores meet the recovery targets
Usually out of scope
- Automatic failover and production traffic changes
- Cross-version migration and other database engines
- Individual table restores
- A deadline for recovery of the entire fleet
What interviewers ask about
- Production impact
- A large copy competes with queries for resources. A remote outage can consume the disk space that production needs.
- Available recovery history
- A valid target needs a usable base and complete recovery history. Recent files alone do not prove continuous coverage.
- Recovery time and correctness
- Recovery work grows between usable bases. A valid backup can miss the deadline even when the base transfer is fast.
- Backup completion and survival
- Files, metadata, keys, and retention rules must agree. A disaster can remove a dependency even when the backup files survive.
Common mistakes
- Uses periodic snapshots without the history required for recovery between them.
- Promises recent recovery times or outage gaps that remote data cannot cover.
- Uses average change volume to justify the recovery deadline under sustained peak load.
- Ignores backup duration, replica lag, or checkpoint history when calculating recovery work.
- Deletes dependencies that support the oldest advertised target.
- Ignores catalog, key, credential, and capacity dependencies during a regional failure.
The bar by level
- Senior (L5/E5)
- Defines durable completion, valid recovery intervals, timeline checks, and safe retention. Proves the recovery budget under peak load. Handles target breaches explicitly.
- Staff (L6+/E6+)
- Includes regional dependencies and reserved capacity in the recovery proof. Quantifies fleet cost. Controls the conflict between production protection, backup deadlines, and recovery coverage.