The problem with starting over

A long download can fail for a hundred ordinary reasons: a flaky connection, a laptop that sleeps, a server that throttles, a window you closed by accident. The naive tool treats all of those as fatal and throws away everything already transferred. On a large playlist over a metered connection, that is not an inconvenience — it is wasted money and time.

Resumability is the discipline of never losing work already done. It is mostly simple, but it is only as strong as the weakest layer that has to cooperate to keep it.

HTTP Range requests, in one paragraph

The mechanism underneath resumable downloads is the HTTP Range header. A client can ask for a specific byte span of a file — bytes 4,000,000 to 7,999,999 — and a server that supports ranges replies with a 206 Partial Content response containing exactly that slice. That single feature lets a downloader fetch a file in independent pieces and, crucially, re-request only the pieces that are missing.

Persisting the session

To resume after the program is closed, the downloader has to remember, on disk, what it already knows:

  • The total expected size of each stream (video and audio are often separate streams that are merged later).
  • Which byte ranges have been verified as written and which are still in flight.
  • A stable identity for the job, so a restart can match the partial file to its queue entry.
  • With all of that persisted, a download interrupted at ninety per cent can continue at ninety per cent — because the program never had to forget anything.

Disk safety while resuming

Resuming is dangerous if you get it wrong: appending to the wrong file, or writing two halves out of order, silently corrupts the result. The safe pattern is to write to a temporary file, track the exact byte offset for every chunk, and only rename it to its final name once every expected byte is present and the merge has succeeded.

Free space has to be checked before the work starts and again while it runs, because a resume can need more room than a fresh download — especially when a video stream and an audio stream are both waiting to be merged.

Retries without being a bad neighbour

When a request fails, the instinct is to fire it again immediately. Servers under load would prefer you did not. A stepped backoff — wait a little, then a little more — recovers from temporary throttling without hammering the source, and classifying errors into readable causes (network, permission, missing video) means a retry is aimed only at the failures that can actually be fixed.

What this means in practice

None of this is glamorous. It is the boring engineering that makes software dependable: check the disk, remember the offset, back off before you retry. That is exactly the kind of work we enjoy, because the user never has to think about any of it — the download just finishes.