Backend coding interview
File Upload Deduplication Coding Interview Problem
What this interview round tests
Design a file upload service — the Dropbox / Google Drive-style question — is a system design interview classic, and its hardest 20% is what this problem isolates: finalizing multipart uploads correctly and deduplicating identical content without ever deleting bytes someone still references.
Interviewers ask it because it layers three real storage-engineering concerns: protocol correctness (a finalize must verify every part is present and intact before assembly), content-addressed deduplication (two users uploading the same file should store it once), and reference-counted cleanup (deleting one user’s file must not destroy the other user’s copy). Each is simple alone; the interview is about keeping them correct at the same time, under concurrent uploads.
The scenario
You are handed the backend of an upload service. Clients start multipart uploads, send parts, and finalize; the service checksums content, deduplicates identical files, and cleans up storage when files are deleted. All the pieces exist, and the test suite fails across all of them.
Finalize succeeds with missing or corrupt parts, two concurrent uploads of identical content create duplicate blobs — or worse, one wins and the other loses data — deleting a deduplicated file strands or destroys the shared bytes, and abandoned uploads leak storage forever. Your job is to make finalization, dedup, and cleanup correct together.
What you’ll practice
- Multipart finalization: verifying part completeness and checksums before assembly
- Content-addressed storage: keying blobs by content hash
- Dedup races: two identical uploads finalizing concurrently must converge to one blob
- Reference counting: delete decrements, and bytes vanish only at zero references
- Idempotent finalize so a retried completion cannot corrupt or duplicate state
- Cleanup safety: abandoned-upload reclamation that never touches live data
How to approach it
Treat finalize as a validation gate followed by a commit: every part present, every checksum matching, and only then assemble and compute the content hash. The hash is the identity — dedup means looking up that identity and linking to an existing blob instead of storing a second copy, which turns the concurrent-identical-upload case into a race you must make convergent.
Cleanup is where careless designs lose data. Make the blob’s reference count the single source of truth: linking increments it atomically, deletion decrements it, and physical removal happens only at zero. Walk the interleavings — a delete racing a new upload of the same content is the case interviewers (and the tests) always probe.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Is this the "design Dropbox" interview question?
It is the part of that question you can actually be graded on: multipart finalization, checksum dedup, and reference-counted cleanup as working code. The architecture-diagram half of "design Dropbox" matters less than whether you can keep these invariants under concurrency.
Why is deduplication tricky under concurrency?
Because identity is discovered at finalize time. Two uploads of the same bytes finish together, both compute the same hash, and both try to become "the" blob. Your design has to make that race converge to one stored copy with two references — without a window where a delete can reap it.
Do I need cloud storage to practise this?
No. The repository models parts, blobs, and references in-process, so every race and failure case is deterministic and the bundled test suite grades your logic directly in Java, Python, or C++.