Design a File Backup System

Design a system that backs up files from a source location to a destination location. The destination must end up with the same directory structure as the source. The system must scale to large file sets and tolerate failures (worker crashes, network errors, partial writes) without corrupting the backup.

Real interview signal (May 2026 phone screen, Software Engineer). The prompt arrives intentionally vague: "design a system to backup files." It is easy to mistake this for an OOD question — candidates often start sketching Backup, File, Folder classes. The interviewer will steer you: "assume these primitives already exist (listDir, stat, readFile, writeFile, mkdir, rename). Focus on how the backup itself works, how the destination ends up structurally identical to the source, how you scale it, and how you handle failure." Recognize that pivot quickly and commit to a system-design walkthrough.

This walkthrough follows the Interview Framework. Because this was a phone screen, the bar is a complete, defensible design with the right pieces — not exhaustive depth on every component. If the interviewer goes deeper on any one area (failure handling is the most common probe here), be ready.

This problem shares techniques with Design Dropbox (chunking, manifests, content hashing). But the goals differ: Dropbox is a multi-tenant sync service for users; a backup system is a one-way mirror tool that emphasizes structure preservation, snapshot consistency, resumability, and restore. Borrow the techniques, not the architecture.