# Dropbox Design Interviews: Why Chunked Upload Is Non‑Negotiable

<img src="https://bugfree-s3.s3.amazonaws.com/mermaid_diagrams/image_1767815201496.png" alt="Chunked upload diagram" style="max-width:800px;width:100%;height:auto;" />

# Dropbox Design Interviews: Why Chunked Upload Is Non‑Negotiable

In a production file-storage system, chunked upload is not an "optimization" — it's the reliability contract. When networks are flaky, chunking turns a full restart into a resume-from-last-success. If you can't explain this flow crisply in a system-design interview, you're not ready.

## The core idea

- Split large files into chunks.
- Upload each chunk independently with a checksum.
- Allow retries per chunk and make chunk upload idempotent.
- Keep an ordered manifest in metadata; store the actual chunks immutably in blob storage.

This transforms a brittle transfer into a robust, resumable process.

## Recommended API flow

1. initiate-upload (returns upload_id, chunk size, auth token)
2. upload-chunk (upload_id, chunk_index, data, checksum) — idempotent
3. complete-upload (upload_id) — verify manifest and seal the file

Why this matters:

- upload-chunk must accept retries without corrupting state. Either overwrite the same immutable chunk or use content-addressed storage and record the reference.
- Checksums (per chunk) detect corruption and avoid replaying invalid data.
- The client can parallelize chunk uploads and retry only failed chunks.

## Storage model

- Metadata DB: stores upload session state and the ordered list of chunk references (manifest). This is the single source of truth for ordering and assembly.
- Blob storage: stores immutable chunk objects (ideally content-addressed). Immutable chunks make retries, dedup, and verification straightforward.

On complete-upload, the server verifies the manifest, optionally composes chunks into a final object (or serves the file by streaming chunks in order), and marks the upload finished.

## Important properties to call out in an interview

- Idempotency: upload-chunk must be idempotent so retries don't create inconsistent state.
- Integrity: checksums per chunk (and optionally an overall checksum) ensure bit-exact reconstruction.
- Resume capability: the client should be able to query which chunks succeeded and continue from the next failed chunk.
- Parallelism: independent chunk uploads allow faster transfers and better utilization of bandwidth.
- Security & auth: short-lived upload tokens and per-request auth minimize abuse surface.
- Garbage collection: abandoned uploads need TTL and cleanup of orphaned chunks.

## Edge cases and implementation notes

- Duplicate chunks: if using content-addressed storage dedupe duplicates naturally; otherwise replace consistently.
- Reordering: the manifest records chunk indices; assembly ignores upload order.
- Partial fails during complete-upload: treat complete as a final transaction — verify all chunks first, then flip state.
- Large scale: use multi-part manifests sharded by range if manifests grow huge.

## Quick interview checklist

- Describe initiate → upload-chunk → complete flow clearly.
- Explain per-chunk checksum, idempotency, and retry behavior.
- Mention where ordering and immutability live (metadata DB vs blob store).
- Call out GC, auth, and how to resume/parallelize uploads.

Chunked uploads are not a "nice to have." They are the fundamental reliability pattern for robust file storage. If you can explain the flow end-to-end and justify each design choice, you’ll demonstrate the system-thinking interviewers are looking for.

#SystemDesign #CloudComputing #SoftwareEngineering