Design a Content-Addressed Photo Storage Service

Read the full interview experience this question came from →

Quick Overview

Design content-addressed photo storage with SHA-256 verification, resumable uploads, transactional metadata, and reference-safe deletion. Treat matching hashes as deduplication candidates rather than authorization, and keep concurrent upload failures from exposing partial objects.

Design a Content-Addressed Photo Storage Service

Company: OpenAI

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

## Prompt Design a photo service that supports upload, view/download, and delete. Every uploaded image must have a SHA-256 digest. Explain where the digest is computed and stored, how identical digests are handled, and how metadata and object blobs stay consistent through concurrent uploads, large-file retries, failures, and deletion. ### Constraints & Assumptions - Photo bytes live in object storage and user-visible metadata lives in a transactional database. - An image must not become visible until the complete object and digest are verified. - Deleting one user's photo must not remove bytes still referenced by another photo record. - Digest equality is treated as a deduplication candidate, not as authorization to read another user's photo. ### Clarifying Questions to Ask - Is deduplication global, tenant-local, or disabled for privacy-sensitive tenants? - Must clients provide a digest, and does the server verify it independently? - What retention, undelete, and legal-hold rules constrain physical deletion? ```hint Separate logical photos from physical blobs Many photo records may reference one verified blob; authorization stays on the logical record rather than the digest. ``` ```hint Publish after verification Keep uploads in a pending state until composition and SHA-256 verification succeed, then commit metadata that readers can discover. ``` ### What a Strong Answer Covers - Upload-session, metadata, blob-reference, and download APIs. - Server-side digest verification and an atomic visibility boundary. - Safe deduplication with reference counting or reachability-based garbage collection. - Idempotency and recovery for concurrent identical uploads and partial failures. - Deletion lifecycle, large-file handling, authorization, observability, and repair jobs. ### Follow-up Questions 1. How would client-side encryption affect global deduplication? 2. How would you detect and repair a reference count that drifted after an outage? 3. How would you serve transformed thumbnails without weakening source-blob integrity?

Overview: Design content-addressed photo storage with SHA-256 verification, resumable uploads, transactional metadata, and reference-safe deletion. Treat matching hashes as deduplication candidates rather than authorization, and keep concurrent upload failures from exposing partial objects.

Read the full OpenAI Software Engineer interview experience this question came from

|Home/System Design/OpenAI
OpenAI logo
OpenAI
Aug 16, 2026
mediumSoftware EngineerTechnical ScreenSystem Design
5
0

Prompt

Design a photo service that supports upload, view/download, and delete. Every uploaded image must have a SHA-256 digest. Explain where the digest is computed and stored, how identical digests are handled, and how metadata and object blobs stay consistent through concurrent uploads, large-file retries, failures, and deletion.

Constraints & Assumptions

  • Photo bytes live in object storage and user-visible metadata lives in a transactional database.
  • An image must not become visible until the complete object and digest are verified.
  • Deleting one user's photo must not remove bytes still referenced by another photo record.
  • Digest equality is treated as a deduplication candidate, not as authorization to read another user's photo.

Clarifying Questions to Ask Guidance

  • Is deduplication global, tenant-local, or disabled for privacy-sensitive tenants?
  • Must clients provide a digest, and does the server verify it independently?
  • What retention, undelete, and legal-hold rules constrain physical deletion?

What a Strong Answer Covers Guidance

  • Upload-session, metadata, blob-reference, and download APIs.
  • Server-side digest verification and an atomic visibility boundary.
  • Safe deduplication with reference counting or reachability-based garbage collection.
  • Idempotency and recovery for concurrent identical uploads and partial failures.
  • Deletion lifecycle, large-file handling, authorization, observability, and repair jobs.

Follow-up Questions Guidance

  1. How would client-side encryption affect global deduplication?
  2. How would you detect and repair a reference count that drifted after an outage?
  3. How would you serve transformed thumbnails without weakening source-blob integrity?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...