Definition
Delta transfer means moving only the changed parts of a file or object instead of transferring the full payload every time.
In file sync, this often means comparing local and remote chunk manifests:
remote version: A B C D
local version: A B X D
upload only X
The system still creates a complete new file version, but it does not need to upload or download every byte.
The Pain That Forces This Concept
Whole-file transfer wastes work.
If a user changes one slide in a large presentation, re-uploading the full file burns bandwidth, battery, storage I/O, and server capacity. If a device comes back online after many small edits, full transfer can make sync feel broken even though the actual changed bytes are small.
Delta transfer exists because user behavior often changes a small portion of a large object.
Mental Model
There are two questions:
What does the new version look like?
Which pieces are missing on the other side?
The first question is metadata. The second question is transfer planning.
A client and server can exchange manifests, compare hashes, then transfer only missing or changed chunks.
How It Works
A practical upload flow:
1. Client has base version v7.
2. Client creates local version v8_candidate.
3. Client computes chunk hashes for v8_candidate.
4. Client asks server which hashes are missing.
5. Client uploads missing chunks.
6. Client commits v8 manifest if base version is still valid or conflict policy allows it.
A download flow is similar. The server tells the client which chunks form the target version. The client downloads chunks it does not already have locally.
Tradeoffs
| Benefit | Cost |
|---|---|
| Saves bandwidth | Requires manifests and hashes |
| Improves mobile sync | Uses CPU for chunking and comparison |
| Makes retries smaller | More metadata requests |
| Supports partial resume | Harder cache and garbage collection |
| Reduces server egress | Needs careful integrity checks |
Delta transfer does not solve conflicts. It only makes byte movement cheaper. The metadata service still decides which version wins or whether a conflict copy is needed.
Operational Reality
Operators should monitor:
- delta hit rate
- bytes avoided by delta transfer
- manifest comparison latency
- chunk lookup latency
- repeated missing-chunk failures
- CPU spent on hashing
- upload resume success rate
- download partial failure rate
Failure modes:
- The client computes chunks against the wrong base version.
- A hash mismatch causes repeated retries.
- The server accepts a manifest before all chunks exist.
- Delta logic saves bandwidth but creates too many metadata calls.
- Very small files pay more overhead than benefit.
- A reconnect storm causes many clients to run expensive manifest comparisons at once.