Resilient Audio Uploads on Unreliable Networks: Chunking, IndexedDB, and Signed URLs

If you are building anything that records audio or video in the browser and ships it to a server, here is the failure mode you will eventually hit: a single long-running HTTP upload, on a real network, dies partway through, and the recording is gone. The fix is not a bigger timeout or a retry wrapper around the whole request. It is chunking the media on the client, caching those chunks somewhere durable, and uploading them independently, so a dropped connection costs you a few seconds of progress instead of the entire session.

We ran into this building TalkBetter, a spoken English evaluation product used by students recording answers over shared campus Wi-Fi. A shared access point serving a lecture hall full of devices behaves very differently from the network you tested on at your desk: connections get renegotiated, NAT mappings expire, packets queue behind everyone else's traffic, and a browser tab in the background can get its network access throttled by the OS. A single-shot upload of a multi-megabyte recording is exactly the kind of long-lived request that dies in that environment, and when it does, the student has to re-record from scratch. That is a bad experience regardless of how good your evaluation model is.

The shape of a chunked upload pipeline

The pattern generalizes to any media-heavy product, not just audio evaluation. It has four stages, and each one has a single job: capture the media and slice it into small pieces; cache those pieces locally so a page reload or a dead tab does not lose them; upload each piece independently with its own retry logic; and finalize the object on the server once every piece has arrived. Getting this right does not require exotic infrastructure — it requires being disciplined about keeping those four stages separate.

Capturing and slicing on the client

The browser's MediaRecorder API already gives you a stream of Blob data at whatever interval you request via the timeslice argument to `start()`. The trick is not to treat every `dataavailable` event as an upload unit — at a one-second timeslice on a typical opus-encoded audio stream, that is far too many small requests. Instead, we buffer the incoming blobs in memory and only hand a chunk off once it crosses a size threshold, in our case 256KB. That number is not a magic constant; it is a balance between chunk overhead (too small, and you spend more time on HTTP request setup than actual transfer) and recovery cost (too large, and a dropped connection loses more progress). For voice recordings, 256KB is roughly 15-20 seconds of compressed audio, which is a reasonable amount of re-recording risk to accept.

Persisting chunks before they ever hit the network

Every chunk that comes out of the recorder gets written to IndexedDB before anything tries to upload it. This is the part people skip, and it is the part that actually buys you resilience. If the tab crashes, the phone locks, or the student accidentally navigates away, the recorded chunks are sitting in durable browser storage, tagged with a session ID and an upload status, and a background uploader can pick up exactly where it left off. Keeping them in a plain in-memory array would mean any of those events loses the whole recording, which defeats the point of chunking in the first place.

Uploading with retries that respect a bad network

A congested Wi-Fi access point does not get better if you throw more concurrent requests at it — it gets worse. Our uploader processes chunks one at a time, in order, rather than firing all pending chunks in parallel. Each chunk gets its own retry loop with exponential backoff and jitter, so a temporary drop causes a short pause and a retry rather than a cascade of failed requests competing for the same limited bandwidth. If a chunk fails after several attempts, it stays marked as pending in IndexedDB and the uploader tries again the next time it runs, including after a page reload.

The server side: signed URLs and finalizing the object

The app server never touches the raw bytes of the recording. Its job is to issue short-lived signed URLs for each chunk, scoped to a specific multipart upload part, and to finalize the object once the client reports every part as uploaded. This keeps the app server's request handlers fast and stateless, and puts the actual bandwidth load on object storage, which is built for exactly this.

Handling a connection that dies mid-chunk, not just between chunks

It is worth being specific about what this design does and does not protect against. A dropped connection between two chunk uploads is the easy case — the failed chunk just retries. The harder case is a connection that dies in the middle of a single PUT request. Browsers do not give you a reliable partial-upload signal for a fetch body, so we treat any non-200 response, thrown error, or timeout as a full failure of that chunk and retry the whole 256KB part rather than trying to resume mid-part. That is why keeping the chunk size small matters: the worst case cost of a mid-chunk failure is bounded by how much you would have to re-send, and at 256KB that cost is small enough not to matter to the user even on a slow connection.

What survives a page reload, and what does not

Because chunks and their upload status live in IndexedDB rather than memory, a page reload does not lose already-flushed chunks — the uploader can resume from `pendingChunks()` on startup and finish sending whatever did not make it out before the reload. What it does not protect against is losing whatever audio was still buffered in memory and had not yet crossed the 256KB flush threshold at the moment of the reload; that portion, at most a few seconds, is genuinely gone. We accepted that tradeoff deliberately — protecting against every possible loss would mean flushing on every `dataavailable` event, which reintroduces the small-chunk overhead problem we chunked in the first place to avoid. Being explicit about where the tradeoff sits, rather than pretending the system is fully lossless, is part of being honest about what this pattern actually buys you.

This is a general-purpose pattern, not something specific to audio. The same four stages — capture, cache, upload, finalize — apply to video capture, large file uploads from a mobile browser, or any client that produces data faster than it can reliably guarantee a network path to send it. If your product records or captures anything meaningful from a user, especially outside a controlled office network, we would treat a single-shot upload as a bug waiting to happen rather than an acceptable simplification.

Product Engineering is where this kind of work lives for us — the unglamorous infrastructure decisions that decide whether a product actually holds up once real users are on real networks, not just on the Wi-Fi in the office where it was built. If you are building something media-heavy and want a second set of eyes on the upload path before it ships to real users, get in touch.