1. Backups and disaster recovery

A bad migration corrupted the main database behind the photo-sharing app, and the interviewer asks how much data you lose and how fast you are back. Two numbers answer it. The RPO (recovery point objective) is the most data you accept losing, measured in time, such as the last 1 minute of uploads. The RTO (recovery time objective) is the longest the service may stay down, such as 1 hour. A backup is a separate copy you can restore to an earlier point in time, and disaster recovery is the plan for getting the service back from it.

The basic principle is to keep a copy that the failure cannot reach, with history you can rewind to, and to size and test it against the RPO and RTO. Reach for it when the system holds data you cannot regenerate, such as uploads, orders, or account records, or when a customer contract puts a number on downtime. Skip it for derived data like thumbnails and caches, which you rebuild from the source of truth, and for the loss of one machine or zone, where replication and failover keep the service up.

This is a frequent follow-up right after a design with replicas, and the whole answer should fit in about 2 minutes, ending on one measured number. Mid-level candidates state the RPO and RTO and say that a replica is not a backup. Senior candidates also pick a backup method that meets the RPO, keep the copies out of production's reach, and say how the RTO was measured. The chapters follow the order of that answer.