What it is
Under the "storage" label sit system design questions where the core deliverable is a place to durably keep large or long-lived content — files, messages, mailboxes, videos — and let it be retrieved, searched, shared, or synchronized across devices. What separates this from a generic "design a service" exercise is the near-universal split into two different storage tiers: a blob/object store for the large, immutable payload (a file's bytes, a video's encoded segments, an email attachment), and a metadata database for the small, frequently-queried structure around it (who owns it, its name, its permissions, its status). Almost every design in this bucket also has to answer a sync or delivery question: how does a second device, a second recipient, or a second reader learn that something changed.
When it applies
- The content itself is large, binary, or long-lived (files, video, attachments) — a relational row can't hold it economically, so it belongs in object storage referenced by a pointer, not embedded in a database record.
- Multiple devices or recipients must converge on the same state (a synced folder, a shared inbox, a group chat) without losing updates or serving stale data indefinitely.
- Durability and retrievability matter more than low-latency computation — the hard part is "never lose this and always be able to find it again," not "compute this fast."
- If the dominant challenge is instead high-frequency numeric aggregation (rolling counts, percentiles) rather than storing and retrieving discrete objects, that's closer to the aggregation pattern than storage.
Tells in the problem
- "Files can be shared with other users" or "a change on one device shows up on others" — a sync/propagation problem layered on top of storage.
- Explicit size and scale numbers for the payload (tens of GB per file, 25 MB attachments, hours of video) that make it clear the content itself needs its own storage tier separate from metadata.
- "Keep a local folder in sync... including offline changes" — conflict detection and resolution (or explicit non-merging) is part of the design, not an afterthought.
- A requirement to transcode, re-encode, or process the content asynchronously after it's accepted (video transcoding, attachment virus scanning) before it's fully available.
- Version history, retention windows, or "restore a previous version" — the storage layer must keep more than just the latest state.
The classic mistake
Designing a single database schema that tries to hold both the payload and its metadata together, then discovering partway through the interview that this doesn't survive the stated scale, is the error that comes up most (large binary blobs blow up database size and backup time; a single store forces every metadata query to compete with heavy blob I/O). It happens because at whiteboard scale a unified "files table with a bytes column" looks simpler to reason about, and the cost only becomes visible once you push on the numbers the prompt already gave you (tens of GB per file, billions of objects). Catch it early by stating up front which store owns the bytes (object storage, addressed by an opaque key) and which owns the queryable facts (a database row pointing at that key) — and then justify only the trade-offs on top of that split, rather than relitigating it.
Questions to start with
- Design a URL Shortener — the smallest possible version of the metadata-plus-pointer split, with no large payload to worry about yet.
- Design an Email Service — adds full-text search and multi-device sync on top of a metadata/attachment split.
- Design a Chat Messaging System — shifts the emphasis from storage durability to ordered, at-least-once delivery across many devices.
- Design Cloud File Storage and Sync — the offline-edit-and-reconcile problem in full: versioning, conflict detection, and sync state per device.
- Design a Video Streaming Platform — the largest payload and the most asynchronous processing pipeline (transcoding) before content becomes readable.