Back to System Design
System Design
File storage
Mid level · full staged walkthrough
Mid
Architecture
MidClientServiceData
Solution, step by step
- 1
Functional requirements
- Upload/download large files
- Folders, sharing, and permissions
- Versioning (optional)
- 2
Non-functional requirements
- Durability 11 nines (object store)
- Resumable uploads for large files
- Strong auth on every access
- Throughput over latency for big files
- 3
Capacity & estimation
- 100M users, 10 GB avg → ~1 EB total storage
- Avg file 1 MB; large files up to GBs → chunk at ~4 MB
- Uploads ~10K/s peak → object store + metadata writes
- Metadata: billions of rows → partitioned DB
- 4
Preliminary design
- Chunk large files; upload chunks to object storage
- Store metadata + chunk map in a DB
- Pre-signed URLs for direct client transfer
- 5
Final architecture
- Metadata service (DB) for files, chunks, permissions, versions
- Object store (S3-like) holds content-addressed chunks; dedup by hash
- Client uploads chunks directly via pre-signed URLs (offload the app tier)
- CDN for downloads; range requests for partial/resumable transfer
- Permission service checked before issuing URLs
Interview Q&A (8)
Chunk them (e.g. ~4MB) and upload chunks independently via pre-signed URLs, enabling resumable and parallel transfer without buffering whole files server-side.
Key components
- Metadata service
- Object store (S3-like)
- Chunker
- CDN
- Auth/permissions
Bottlenecks & how to address them
- Metadata hotspots → partition by user/folder
- Large-file memory → stream, never buffer whole files
- Permission checks on every read → cache ACLs
Tradeoffs to articulate
- Chunk size vs overhead
- Dedup vs simplicity
- Strong vs eventual metadata consistency
Where this content comes from
For full transparency, this content is curated and verified from these sources:
Published architecture case studiesCompany engineering blogsOppZen design rubric library