The marker cap had barely clicked open when the interviewer finished the prompt: “Design an image storage system.” Within a minute, three familiar boxes could have appeared on the whiteboard: object storage for the files, a database for metadata, and a CDN for delivery.
None of those components is unreasonable. The problem is their timing. The candidate has started answering before the question has enough shape to support an answer.
An image storage system might hold profile pictures for an internal application, preserve private family backups, serve a public social feed, or process millions of product photos. Each system stores images, but each protects a different promise. A backup service may place durability and recovery above immediate display. A public feed may care more about read traffic, thumbnails, moderation, sudden popularity, and delivery across regions. The architecture changes because the product meaning changes.
That is why the first question in a System Design Interview is rarely “Which technology should I use?” A more useful question is “What must this system do well?” Who uploads the images, who reads them, whether they are public or private, how long they remain, and what must happen after an upload are not details to fill in later. They decide the design.
Scale makes this visible. Registered users alone tell us little. Active users, uploads per day, average object size, read-to-write ratio, geographic distribution, and retention tell us much more. If we explicitly assume two million uploads each day at an average of 4 MB, the original objects alone add about 8 TB per day, or nearly 3 PB per year. That is not a forecast. It is a quick way to expose the next questions about compression, image variants, replication, lifecycle policies, egress cost, and deletion.
The core flows need the same care. Does the first version only upload and display images, or must it also edit, share, search, and delete them? Does the service resize, compress, scan, or remove sensitive metadata? Must a thumbnail appear in the upload response, or may processing continue asynchronously? Search by filename, structured metadata, and visual content are three very different requirements hiding behind the word “search.”
Non-functional requirements turn those flows into engineering constraints. What latency is acceptable? What availability and durability are expected? How much data could be lost if a region failed? Must a revoked private image become inaccessible immediately at every cache? Consistency is not one switch for the whole system: a view counter may tolerate eventual consistency, while access control and an image marked ready may need stronger guarantees.
The interviewer may not provide every number, and that is not a dead end. The candidate can make an assumption visible and continue: “I will assume this is a public, read-heavy photo-sharing service with one million daily active users, thumbnail generation, and users concentrated in Southeast Asia. If that scope works, I will design the upload and read paths first.” A spoken assumption can be corrected. A silent one can steer the entire interview toward the wrong system.
Clarifying requirements does not mean spending half the session reading a checklist. The useful questions are the ones that can change the architecture. In the first few minutes, establish the primary use case, a rough scale envelope, the most important constraints, and the success criteria. Then summarize the scope, name what will stay out of scope, and begin the design.
Only then do familiar components earn their place. Object storage may fit large blobs that need high durability. A metadata database may hold ownership, object keys, access rules, and processing state. Direct uploads through pre-signed URLs may keep large files away from application servers. A queue may separate upload acceptance from resizing or scanning. A CDN may reduce latency for a read-heavy public workload. These are no longer memorized boxes; they are responses to named requirements.
The same reasoning reveals the uncomfortable gaps between boxes. What happens if the object upload succeeds but the metadata write fails? Can a worker safely create the same thumbnail twice after a retry? Could metadata say ready before every required variant exists? How is a deleted private image removed from CDN caches? How are orphaned objects found and cleaned up? These failure paths often say more about engineering judgment than another service added to the diagram.
Drawing too early is understandable. Tools feel concrete, and a busy whiteboard feels like progress under time pressure. But a System Design Interview is not only a test of how many technologies someone remembers. It is also a conversation about turning ambiguity into a solvable scope, making assumptions inspectable, and connecting every trade-off to a real need.
A complex diagram can show technical vocabulary. A few careful questions at the beginning show what that vocabulary is for. The next time a prompt arrives in one short sentence, it may be worth keeping the marker still long enough to say: “Before proposing the architecture, I would like to clarify the primary use case and the constraints that could change the design.”
That pause is not the absence of an answer. It is the beginning of a responsible one. If you have taken part in a System Design Interview, which clarifying question changed the design that followed?