How the interviewer opens it
“Design a service that lets users download video or music and play it offline. Downloads must survive connection failures and obey storage limits and content expiration.”
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
- Clients and playback
- Scale and media size
- Read and write traffic
- Latency
- Storage policy
- Expiration and revocation
- Consistency and availability
- Existing services
- Durability
- Scope exclusions
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
- Download media with pause and resume support across connection failures and device restarts.
- Play complete downloads without a connection.
- Enforce a local storage quota and a free-space reserve.
- Enforce content expiration during offline playback.
Usually out of scope
- Play incomplete downloads.
- Change media quality during a download.
- Transfer downloads between devices.
- Build the media encoding pipeline or the DRM service.
- Protect against a fully compromised operating system.
What interviewers ask about
- Transfer progress
- Connections, URLs, media versions, and app processes can change independently. A false progress record can corrupt the final file.
- Local storage
- Downloads compete for limited space while other apps consume the same disk. File changes and database changes cannot share one transaction.
- Offline access
- An offline device cannot receive immediate revocation. A user can also change the wall clock or prevent background cleanup.
- Background progress
- The OS controls execution after app suspension. Large groups of devices can also resume together after a network outage.
Common mistakes
- The design focuses on servers and omits durable state on the device.
- The client treats a temporary URL as the identity of a media file.
- The client ignores partial files or relies only on disk-full errors to protect the storage reserve.
- The design treats the wall clock as trusted proof of license validity.
- The design promises background execution or immediate offline revocation without platform support.
- The client assumes that file publication and a database update form one atomic operation.
The bar by level
- Senior (L5/E5)
- Defines recovery across file writes, checkpoints, publication, and deletion. Reserves capacity atomically and checks the reserve before bounded writes. Handles disk-full failures and late task results. Uses native background transfers and trusted license expiry.
- Staff (L6+/E6+)
- Defines correctness across OS tasks, local files, metadata, and licenses. Bounds repeated transfers and fleet retry traffic. States the limits of offline revocation, background execution, and free-space guarantees. Changes the product contract when new requirements exceed those limits.