How the interviewer opens it
“Design a platform where people upload, search for, and share animated GIFs. The platform must serve GIFs inside other apps and websites with low latency.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Catalog and upload volume
- Read volume and peaks
- Media limits and size
- Search behavior
- Share behavior and clients
- Latency and freshness
- Availability and consistency
- Upload durability and publication
- Deletion and policy removal
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Accept GIF uploads and show their status
- Search approved GIFs by caption and tags
- Share a page link or a direct media URL
- Serve embedded media worldwide and enforce removals
Usually out of scope
- Personalized recommendations and social feeds
- Private libraries and paid content
- A custom content policy classifier
- Removal of downloaded files or third-party copies
What interviewers ask about
- Upload safety and status
- A small GIF can expand into many frames and consume much more memory than its file size suggests. Publication also depends on several independent tasks.
- Global media delivery
- Media bytes dominate cost and capacity. One popular GIF can overload an origin even when total catalog traffic appears manageable.
- Search results
- A billion GIFs require selective text lookup. Asynchronous updates and changing popularity can produce stale results or unstable result pages.
- Removal propagation
- Existing embeds keep old URLs. Copies at several cache layers can outlive a database deletion and continue to serve forbidden media.
Common mistakes
- Designs search but ignores the media bandwidth and embed traffic.
- Publishes raw uploads before validation and policy approval.
- Uses one large GIF version for previews and every client.
- Assumes the metadata store and search index change atomically.
- Uses permanent browser caches without a workable removal rule.
- Adds a custom video protocol or recommendation system before meeting the core requirements.
The bar by level
- Mid-level (L4/E4)
- Defines upload, search, and share APIs. Separates metadata from media storage. Uses a text index and CDN. Explains upload status and basic deletion.
- Senior (L5/E5)
- Quantifies media bandwidth and origin load. Handles unsafe files, duplicate jobs, index delay, and partial publication. Bounds removal across caches and explains origin failure behavior.
- Staff (L6+/E6+)
- Defines end-to-end publication and removal guarantees. Tests these guarantees during regional partitions and delayed events. Relates cache policy to origin cost and removal deadlines. Sets safe capacity limits for media work, review backlogs, and cold-cache traffic.