System Design: [Photo sharing service name]

Reference design for an Instagram-style photo sharing service: resumable upload straight to object storage, an asynchronous media pipeline that produces thumbnails and display sizes, storage tiers from hot to cold, profiles and a follower feed, a time-sortable 64-bit id scheme, sharded PostgreSQL for metadata, celebrity fan-out, and CDN delivery. It follows the structure of the System Design Document template, adds a 45-minute interview path, and is pre-filled with a worked design to adapt. Replace every [bracketed] value and every row marked Example; numbers marked Example are assumptions to recompute.

Document control

Approvals

Revision history

Contents

1. Overview
2. Requirements
3. Capacity estimation
4. API design
5. Data model
6. High-level design
7. Detailed design
8. Scalability and performance
9. Reliability, security and operations
10. Trade-offs and alternatives
11. Delivery plan and risks
12. Appendices

1. Overview

1.1 Problem statement

[Example: The current service stores photos on application servers' disks and metadata in one PostgreSQL primary. Uploads time out on mobile networks, thumbnails are generated synchronously inside the upload request, the primary is at 80% CPU and 4 TB, and a celebrity post causes a write storm into millions of feed rows. Growth to 100 million uploads per day is planned within 18 months.]

1.2 Proposed solution

[Example: Clients resize and compress photos, then upload them directly to object storage with a resumable, pre-authorised upload session. A finalize call creates the media record with a 64-bit time-sortable id and publishes an event; workers generate display sizes, strip sensitive metadata, run safety checks and mark the media ready. Metadata lives in PostgreSQL sharded by user id across thousands of logical shards. Feeds use fan-out on write into per-user timelines in a key-value store, except for accounts above a follower threshold, whose posts are merged at read time. Images are served through a CDN from versioned, immutable URLs; storage moves from replicated hot storage to erasure-coded warm storage after 30 days.]

1.3 Decisions requested from reviewers

1.4 45-minute interview path

Separate the write path (upload) from the read path (view) early; they have different bottlenecks and the interviewer will want both.

2. Requirements

2.1 Core functional requirements

2.2 Non-functional requirements

2.3 Below the line (out of scope)

• [Example: video, stories and live (see Video Streaming System Design (system-design/design-video-streaming))]
• [Example: feed ranking models (this design delivers candidates; ranking is a separate service)]
• [Example: direct messages (see Chat System Design (system-design/design-chat-system))]
• [Example: search and hashtag pages]
• [Example: image editing filters beyond what the client applies before upload]
• [Item deferred, with the release that will take it]

3. Capacity estimation

3.1 Assumptions

3.2 Uploads

• Average: 100 million / 86 400 s = about 1 160 uploads/s; peak about 3 500/s.
• Peak ingest bandwidth: 3 500 x 1.5 MB = 5.25 GB/s, about 42 Gbit/s. Consequence: bytes must not pass through application servers; clients upload directly to object storage (7.1).

3.3 Storage

• Per day: 100 million x 2 MB = 200 TB.
• Per year: 200 TB x 365 = 73 PB of logical data.
• With 3 replicas for 30 days and erasure coding at 1.4x afterwards, the physical footprint after one year is about 200 TB x 30 x 3 + 200 TB x 335 x 1.4 = 18 PB + 93.8 PB, about 112 PB. Keeping 3 replicas for the whole year would need 219 PB. Consequence: tiering halves the storage bill; views drop sharply after the first days, so warm storage is acceptable for older media (7.4).

3.4 Views and egress

• Average: 25 billion / 86 400 s = about 289 000 views/s; peak about 870 000/s.
• Peak egress: 870 000 x 150 KB = about 130 GB/s, about 1 Tbit/s. Consequence: a CDN is mandatory. At a 95% CDN hit rate the origin serves about 6.5 GB/s, which still needs an origin shield tier in front of object storage.

3.5 Metadata

• Media rows: 100 million/day x 1 KB = 100 GB/day, about 36.5 TB/year, plus likes and comments at several times that. Consequence: one PostgreSQL primary cannot hold this; metadata is sharded from the start, with logical shards so the physical layout can change later (7.2).

3.6 Feed fan-out

• Average 200 followers per poster: 100 million posts x 200 = 20 billion timeline inserts/day, about 231 000/s on average.
• An account with 50 million followers would add 50 million inserts for one post. Consequence: fan-out on write for most accounts, fan-out on read above a threshold (7.3).

3.7 Summary

4. API design

4.1 Endpoints

4.2 Request and response examples

Finalize after the upload completes. The id is a 64-bit integer returned as a string so JavaScript clients do not lose precision.

POST /v1/media
Idempotency-Key: 8d4c2f0e-6a1b-4c55-9f2e-0b7c1d9a3e11
Content-Type: application/json

{"upload_ids": ["up_7Hq2"], "caption": "Morning run", "audience": "followers"}

{"media_id": "3477619814263193600", "status": "processing", "author_id": "1028", "created_at": "2026-10-22T07:12:44Z"}

4.3 Errors, limits and pagination

5. Data model

5.1 Entities

Metadata is relational; bytes live in object storage; timelines live in a key-value store.

5.2 Storage choices

5.3 Access patterns

6. High-level design

7. Detailed design

7.1 Deep dive 1: upload and media pipeline

Problem. Uploads must survive flaky mobile networks, must not tie up application servers, and the post must appear quickly even though resizing and safety checks take seconds.

Choice. C.

Reason. The 42 Gbit/s peak ingest (3.2) goes straight to storage built for it. Resumable chunked upload survives network changes. The author sees the post immediately from a local copy while processing runs; followers get it once status becomes ready.

Processing steps, each idempotent so a retried message is safe:

1. Verify the file type by content, not by extension; reject anything the decoder does not recognise.
2. Decode in a sandboxed worker with memory and time limits.
3. Apply orientation, strip location and device metadata.
4. Produce display sizes (Example: 150, 320, 640, 1 080 px wide) in WebP and JPEG, keyed by content hash and size.
5. Run safety classification and known-harmful-content hash matching; hold for review when flagged.
6. Mark ready and emit media.ready.

A daily job deletes uploads that were never finalized after 24 hours.

7.2 Deep dive 2: ids and sharding

Problem. Ids must be unique across thousands of shards, sortable by time for paging, compact (64 bits), and must tell the router which shard holds the row.

Choice. D, with this layout (Example):

Reason. Paging by id is paging by time, so the profile grid and timeline need no separate time index. The shard is part of the id, so a post URL routes without a lookup. Generating the id inside the shard's database (a stored function using the shard's own sequence) keeps it unique without a new service.

Logical shards are mapped to physical hosts through a small versioned map. Each logical shard is a separate schema, so moving it to a new host is a replication copy plus a map update, with no id changes. Example: start with 8 192 logical shards on 64 hosts (128 per host) and split hosts as they fill.

How real systems do it (paraphrased from the Instagram Engineering post "Sharding & IDs at Instagram", 2011; inspiration only). The post explains why the team kept PostgreSQL and sharded it instead of moving to a different database, and how it generated unique ids once inserts were spread across many databases. Its id goals were time sortability and a 64-bit size, and its scheme composed a time component, a logical shard id and a per-shard sequence, generated inside PostgreSQL. Data was split into many logical shards placed on fewer physical servers, so shards could later be moved without changing ids. The post describes the system as it was in 2011; check it for the exact layout and reasoning.

7.3 Deep dive 3: celebrity fan-out

Problem. Fan-out on write gives fast feed reads but explodes for accounts with millions of followers; fan-out on read is cheap to write but expensive for every feed load.

Choice. C with a threshold of Example: 200 000 followers. Pushes skip followers inactive for 30 days; they rebuild their timeline on next login.

Reason. Most posters are small, so push covers most posts cheaply. A typical reader follows a handful of large accounts, so the read path merges fewer than Example: 20 celebrity lists, each served from a cache of that account's latest posts. See News Feed System Design (system-design/design-news-feed) for ranking and timeline storage detail.

7.4 Deep dive 4: storage tiers and CDN

Problem. Storage grows by 73 PB a year while most views hit recent photos.

Choice. B for all served sizes, C for originals not needed for serving. Served sizes are generated at upload, so the archive tier is read only when a new size must be produced.

Reason. The CDN absorbs repeat views, and warm storage latency is paid only on CDN misses for old photos. Image URLs contain the content hash (/{hash}/640.webp), so they are cached with a long immutable lifetime; deletion removes the database row, revokes the path and purges the CDN.

7.5 Privacy and deletion

Private accounts serve images through signed URLs with short expiry (Example: 1 hour) so a leaked URL stops working. Deletion marks the media row, removes timeline entries asynchronously, purges CDN paths, and deletes bytes from storage after a recovery window of Example: 30 days.

8. Scalability and performance

Latency budget for the first feed image (target p75 500 ms on mobile):

9. Reliability, security and operations

9.1 Failure modes

9.2 Security and abuse

9.3 Observability

9.4 Cost estimate

10. Trade-offs and alternatives

10.1 Decisions

10.2 Alternatives considered

• On-demand resizing at the edge. Fewer stored bytes, any size on request, but a cold cache costs decode time on the critical path and ties you to an edge compute product. Reasonable at 0.1x.
• A dedicated blob store with needle-style files. Large photo platforms have built their own stores to cut per-file metadata overhead; object storage is chosen here until per-object request cost dominates.

11. Delivery plan and risks

11.1 Milestones

11.2 Rollout and rollback

[Example: Enable the new upload path per app version and per country. Rollback returns clients to the old upload endpoint, which remains deployed until M3. Metadata migration dual-writes until the backfill is verified.]

11.3 Risks

12. Appendices

12.1 Open questions

12.2 Glossary

12.3 References

Inspiration only; no text, diagrams or figures are copied.

Standard and licence note

Based on common industry practice for photo sharing services and on the public write-ups and RFCs listed in 12.3, which are cited as inspiration only. This is a reference design to adapt, with illustrative numbers. Original text written for this collection; check the cited sources for the exact mechanisms they describe. Template licence: MIT.