Design a Blob Storage Service
Design a highly available blob storage service similar to S3 — or, in its product framing, a Google Photos-like service: users upload files or photos, retrieve them from anywhere, and never lose data.
Cover: the split between the metadata plane and the data plane, the write path and where the object atomically comes into existence, replication versus erasure coding, what background processes keep the system healthy, and — for the Photos framing — dedup and quotas.
Hints
Hint 1
Separate planes: object name → chunk list, versions, and ACLs in a sharded strongly consistent metadata store; immutable content-addressed chunks of a few MB on storage nodes placed by a placement service.
Hint 2
The metadata commit is the atomic 'the object exists' moment — chunks written first, metadata last. Everything a crashed client leaves behind is orphaned chunks for GC.
Hint 3
Have the replication-vs-erasure-coding numbers ready: 3× replication is 200% overhead and fast reads; 10+4 erasure coding is 40% overhead with costlier reads and repairs.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.