Practice a File-Upload Design Review for Interrupted Transfers

TL;DR

• In this fictional upload exercise, incomplete data must remain distinct from a finished file.
• Track an upload session and resume from server-confirmed progress, then verify completion before exposing the file.
• Make finalization retryable, bound retention, and rehearse interrupted transfers and uncertain outcomes.

Make incomplete data an explicit state

Practice this fictional prompt: users upload large files over unreliable connections. A connection drops near the end, and the client does not know whether the server received the final bytes. Design a resumable upload flow that avoids corrupt files and does not expose incomplete content as ready for use.

Start with the product's requirements: maximum size, allowed content, authentication, storage destination and what makes a file available. Resuming byte transfer is only one part of the design. Validation, ownership, completion and cleanup need their own states and decisions.

Separate the upload session from the finished file

Create an upload session with an identifier, owner, expected constraints and current progress. Treat its bytes as temporary until the service verifies completion and the required checks succeed. A storage object existing does not by itself mean the application should serve it.

A possible state model for the exercise is:

The exact names are not important. The explicit distinction between received and ready is important because processing can fail after every byte arrives.

Resume from server-confirmed progress

When the connection fails, the client should query the session's authoritative progress rather than guess from the bytes it attempted to send. The server may have received more or less than the client knows. Appending from the wrong position can duplicate or omit data.

The tus resumable-upload protocol provides a primary example using upload offsets and requests that verify progress. It is a concrete protocol to study, not a requirement that every design adopt it. If you propose chunk identifiers instead, explain how ordering, duplication and missing chunks are handled.

Define what happens when two clients try to continue the same session concurrently. Rejecting an unexpected offset or serializing updates can protect the session's state. Do not assume one browser tab means only one request can ever be in flight.

Verify completion before publishing availability

An expected byte count can establish transfer completeness, but it does not prove the content is valid or safe to process. Check the required file constraints and any integrity mechanism appropriate to the design. Do not trust a filename extension as the sole description of content.

If the client provides a checksum, explain what it proves and how it is validated. A checksum can detect transfer differences relative to the supplied value; it does not establish that the sender's file is benign. Keep integrity, content validation and authorization as separate concerns.

Our system design frameworks guide can help organize these boundaries. The interview answer should say which event transitions the file to ready and what remains unavailable before that event.

Make finalization retryable

Suppose all bytes arrive and validation succeeds, but the final response is lost. A repeated finalize request should not create a second logical file or trigger uncontrolled duplicate processing. Use a stable session-to-file relationship and a defined completed result.

If processing runs asynchronously, record the intended work durably and make worker retries safe. A crash between object storage and database updates can leave an orphan or an uncertain state; explain how reconciliation identifies it. Do not claim that two separate storage systems commit atomically unless your design actually provides that property.

The client needs a way to ask whether the session is uploading, processing, ready or failed. A spinner with no recoverable status forces users to start over when the final response is uncertain.

For a direct-to-storage design, explain how the application confirms that the completed object belongs to the authorized session and satisfies its constraints. A callback or client message saying upload complete is evidence to verify, not sufficient authority to publish any supplied object key. Bind finalization to the session’s expected destination and owner before exposing the resulting file.

Bound retention and rehearse failure cases

Incomplete sessions consume storage and operational attention. Define expiration, cleanup and the user-visible response when a session is no longer resumable. Keep cleanup from deleting an object that a valid completion path has already adopted; use clear ownership and state checks.

Test a disconnect before a chunk is accepted, after it is accepted but before acknowledgement, during validation and after finalization. Include an unauthorized attempt to inspect another user's session. The upload identifier is not a substitute for access control.

Use the mock interview strategy guide to retry the exercise with several parallel chunks. A strong answer explains authoritative progress, safe retries, explicit completion states and eventual cleanup. The design should make uncertainty recoverable without pretending that partially received bytes are already a finished application file.