Stage 7 of 7 · Defend it
Dropbox-Style File Sync Service: Delete now; reclaim bytes only when safe
Deleting one path may not make its blocks unreachable: another version or another file may reference the same content. A restore can also race with a cleanup job that previously saw no references.
System so far· 5 parts
Select a component to see what it is responsible for and which state it owns.
- 1Desktop and mobile clients → File API: Upload, download and sync requests
- 2File API → Metadata service: Conditional metadata operations
- 3Metadata service → Metadata database: Commit version and append journal row
- 4Metadata database → Change notifier: Journal advanced
- 5Change notifier → Desktop and mobile clients: Wake, then page from cursor
- Request / response
- Asynchronous
- Server push
What you need to know
Make delete a metadata operation first: append a tombstone, remove the version from the active namespace, and preserve it for the product's retention window. A collector finds blocks unreachable from all retained manifests, but a stale mark is not permission to delete immediately. Recheck reachability and wait beyond the maximum metadata replication and in-flight upload delay.
At large scale, immutable blocks simplify reads and retries but move complexity into reclamation. Garbage collection identifies unreferenced content; compaction is the physical work that makes space reusable. Dropbox's public Magic Pocket posts describe this trade-off in its own storage system; the exercise uses it as an operational lesson, not as a claim that this design matches their implementation.