Design a File Upload Feature

A user drags a PDF into a chat window and asks a question about it. That one gesture is the whole prompt, and it hides two systems that happen to share a button. The first is an ordinary large-file upload service. It accepts bytes reliably over a flaky network, stores them durably, and never loses or corrupts a file. The second exists only because the other side is a model. It takes those bytes, pulls text out of them, and fits that text into a context window far smaller than the file. Name both halves early. A candidate who designs only the upload plumbing has answered a generic question. One who jumps straight to the model has skipped the durability the feature stands on.

Work outward from the file itself. It can be large, so it will not arrive in one request and cannot be held in memory. It comes from a browser on a home connection, so the transfer will break and has to resume rather than restart. It is untrusted. Anyone can upload anything, so it has to be scanned before the system leans on it. And it is destined for a model with a hard context limit, so its text has to be extracted and cut down to fit. Big, flaky, hostile, bound for a small window. Those four facts drive every decision that follows. Pin them first, then draw boxes.

The xAI angle

The uploaded file is the moment an outside document meets your model, and both of those are risky at once. A generic upload service worries about durability and bandwidth. A file feeding an AI chat carries a second hazard. The bytes are untrusted, and a model is about to read them and act on what they say. A malware-laden attachment is the old threat. The newer one is a document whose text quietly instructs the model, a prompt-injection payload riding inside an innocent-looking file. So the design has two gates. Validate and scan the bytes as a file, the way any upload service must. Then treat the extracted text as untrusted input to the model.