How the interviewer opens it
“Design a system that moves petabytes of a customer's data from their own data center to a cloud provider like Google Cloud. The customer wants minimal downtime and confidence that everything arrived correctly.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- dataset and semantics
- source capabilities
- read:write mix and change volume
- network and source limits
- deadline and destination
- downtime
- latency and catch-up
- consistency, availability, and durability
- verified integrity
- out of scope
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Copy a consistent baseline while the source remains in use
- Capture and apply creates, updates, and deletes made during the migration
- Resume interrupted transfers and verify completeness and content integrity
- Move application traffic to the destination without losing acknowledged writes
Usually out of scope
- Migrating arbitrary database engines or preserving POSIX filesystem semantics
- Application rewrites and schema transformations
- Migrating historical object versions
- Building a physical transfer appliance
What interviewers probe
- A consistent snapshot plus changes, without resurrecting old data
- The copy takes over a month while objects are replaced and deleted. A successful upload can still leave the wrong final state if snapshot data and journal events are applied in the wrong order.
- Finishing within the bandwidth budget without hurting production
- The baseline nearly consumes the available migration window, and ongoing changes consume capacity too. Retries, small-object overhead, or an overloaded source can turn a plausible plan into one that never catches up.
- Proving completeness and byte integrity at petabyte scale
- Checksums on copied objects do not reveal an omitted object, an incorrect delete, or a stale version. A full final source scan would also violate the downtime budget.
- A five-minute cutover with one authoritative writer
- Low replication lag is not proof that all acknowledged writes were copied. Old clients, in-flight requests, and a partially failed traffic switch can create two writers or lose the final changes.
Common mistakes
- Treating the problem as a parallel file copy and ignoring concurrent replacements and deletions.
- Using advertised bandwidth rather than useful throughput, or omitting change traffic from the completion estimate.
- Retrying mutable source reads without a stable version, producing mixed or unverifiable content.
- Claiming integrity from upload success, byte counts, or checksum metadata that was never independently checked.
- Saving progress only in worker memory or advancing a checkpoint past failed work.
- Leaving cutover as 'switch DNS' and promising rollback without accounting for new destination writes.
The bar by level
- Senior (L5/E5)
- Defines exact snapshot/log boundaries, idempotent replay with deletes, durable transfer checkpoints, independent byte and inventory verification, and a fenced cutover. Quantifies effective bandwidth, change backlog, and completion time; explains worker crashes, upload retries, and journal gaps.
- Staff (L6+/E6+)
- Makes the whole migration operationally safe: proves that retention and throughput cover the deadline, separates logical consistency from byte verification, identifies source and destination bottlenecks, and uses explicit readiness and abort gates. Handles ambiguous cutover failures, post-switch rollback limits, resource and request costs, and requirement changes without defaulting to unsafe dual writes or unnecessary infrastructure.