Katkat
Back

Design a Content-Addressed Photo Storage Service

OpenAISoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a scalable, content-addressed photo storage service with cryptographic verification, resumable chunked uploads, reference-counted deduplication, and protections against unauthorized hash-probing attacks.

Scenario

Design a multi-tenant, content-addressed photo storage service (similar to the underlying object layer of modern media and AI platforms). The service must globally deduplicate photos across users using cryptographic hashing (SHA-256) while guaranteeing strict tenant isolation, transactional integrity, and reference-safe lifecycle management.

Requirements

Functional Requirements

  • Resumable Uploads: Support reliable, chunked uploads for images up to 50 MB, handling network interruptions gracefully.
  • Content-Addressed Storage & Integrity: Calculate and verify the SHA-256 digest both during ingestion and at rest. Corrupted chunks or mismatched final digests must be rejected.
  • Safe Deduplication: If an identical image has already been uploaded, reuse the underlying stored blob without storing duplicate raw bytes.
  • Security & Authorization: Merely knowing or guessing a SHA-256 hash must not grant read access or allow a tenant to claim a file without proving possession of the image bytes.
  • Reference-Safe Deletion: Deleting a user's photo must decrement reference metadata. The underlying physical blob must only be purged when no active user references exist.
  • Fault Isolation: Interrupted or failed uploads must never leave partial objects visible or corrupt existing canonical blobs.

Non-Functional Requirements & Scale

  • Daily Ingestion: 50 million photos uploaded per day (~200 TB/day raw, assuming average photo size of 4 MB).
  • Read Traffic: 500 million reads per day (~10:1 read-to-write ratio).
  • Durability: 99.999999999% (11 9's) durability for committed objects.
  • Consistency: Strong consistency for upload completion and reference counting; eventual consistency is acceptable for physical blob cleanup.
  • Latency: P99 download latency < 150 ms (excluding client network transit).

What Your Design Should Cover

  1. API Design: Core endpoints for upload initiation, chunk transfer, commit/finalize, retrieval, and deletion.
  2. Data Model & Schema: Separation between user-facing metadata/references and underlying physical content records.
  3. Upload & Verification Lifecycle: Staging, chunk assembly, SHA-256 verification, and atomic commit.
  4. Security Model: Defenses against proof-of-ownership vulnerabilities and side-channel existence probing in deduplication.
  5. Garbage Collection: Mechanism for cleaning up orphaned blobs and abandoned upload sessions without data races.

Hints

Hint 1

Decouple logical user file references from physical content blobs by storing them in separate tables linked by the content hash.

Hint 2

To prevent hash-guessing attacks during client-side deduplication, enforce a proof-of-ownership protocol or require clients to stream the data into an isolated staging bucket before linking.

Hint 3

Store in-flight upload chunks in temporary storage and use an atomic transactional commit (or two-phase commit) when transitioning a staged upload to a canonical blob.

Follow-up questions

  • How would you implement an asynchronous garbage collection pipeline that cleans unreferenced blobs without racing against an in-flight upload that references the same hash?
  • How would you adapt the system if you wanted to implement perceptual hashing to flag duplicate or near-duplicate media for moderation without breaking cryptographic deduplication?
  • If a client claims to have an existing file by sending its SHA-256 hash, how can the server verify proof-of-ownership without requiring the client to re-upload the entire file over a slow uplink?