Photo Sharing

Problem Statement & Requirements

Functional Requirements

• Upload photos -- users upload images with caption, tags, location, and filters
• News feed -- see a personalized feed of photos from followed users
• Follow/unfollow -- follow other users to see their content
• Like & comment -- interact with posts
• Explore / discover -- browse trending and recommended content
• Stories -- ephemeral 24-hour photo/video content (brief mention)
• User profiles -- view user's posts grid, follower/following counts, bio
• Search -- search by username, hashtag, or location
• Notifications -- new followers, likes, comments, mentions

Non-Functional Requirements

• High availability -- 99.99% uptime
• Low latency -- feed loads in < 500 ms, image loads in < 200 ms
• Consistency -- eventual consistency acceptable for feed; strong for follow/unfollow
• Read-heavy -- read:write ratio ~100:1
• Scalability -- 500M+ DAU, 100M+ photos uploaded/day
• Durability -- uploaded photos never lost

Out of Scope

• Reels / short-form video (covered in video streaming design)
• Messaging / DMs (covered in chat system design)
• Ads / monetization platform
• Shopping / e-commerce integration

Scale Estimations

Users & Content

Storage

Traffic

Bandwidth

High-Level Architecture

Detailed Architecture

Workshop note · added for the website’s common reading format

For Photo Sharing, define contracts around the boundary components: Mobile client, API gateway, Post service. Specify authentication, request identity, versioning, pagination or streaming semantics, timeouts, and retry behavior. Name which operations are idempotent and how callers discover an uncertain outcome.

The source discusses these contracts within its subsystem walkthroughs rather than as a standalone endpoint catalog. The examples in this article are design exercises, not published service APIs.

Data Model

Posts Table (MySQL / Vitess)

Social Graph (Follows)

Likes & Comments

News Feed -- The Core Design Challenge

Fanout-on-Write vs Fanout-on-Read

This is THE critical design decision for Instagram/Twitter-like systems.

Hybrid Approach (Instagram's Actual Design)

Photo Upload & Processing Flow

Image Processing Pipeline

Feed Generation Flow (Detailed)

Feed Pagination (Cursor-Based)

Feed Cache Design (Redis)

Feed Ranking (Beyond Reverse Chronological)

Blob Storage & CDN

Fanout Service Detail

Explore / Discover Page

Stories (24-Hour Ephemeral Content)

Search

Workshop note · added for the website’s common reading format

Walk through three failure moments in Photo Sharing: a request times out before its result is known; a dependency becomes slow rather than unavailable; and a process restarts after committing state but before acknowledging it.

For each case, name the authoritative record, define a safe retry, cap resource usage, and describe what the caller sees. Telemetry should help detect and contain the problem: Watch processing backlog, feed staleness, and image delivery failures separately.

Tradeoffs & Design Decisions Summary

Workshop note · added for the website’s common reading format

Watch processing backlog, feed staleness, and image delivery failures separately.

Set service-level objectives for the user-visible path, then map its dependencies. Define bounded retries with jitter, deadlines, and backpressure. Keep a degraded mode that protects authoritative state, and test recovery instead of treating replication as a backup.

For Photo Sharing, pay special attention to Blob store + CDN, Feed cache, Social graph when deciding failure domains and recovery procedures.

Production Architecture

Workshop note · added for the website’s common reading format

Rebuild Photo Sharing from memory, then change one assumption: ten times more traffic, a new region, or a stricter consistency requirement. Which component must change first—and which does not?

Compare Post service with the same boundary in a related design. Write down one alternative you rejected, what it would simplify, and when you would choose it instead. Follow the source link at the end of this article to explore the original document.

Interview Tips

1. Start with the feed -- "The core challenge of Instagram is generating a personalized feed for 500M daily users. Let me design the feed system first." This shows you know what matters.

2. Fanout-on-write vs fanout-on-read is THE question -- Draw both approaches. Explain the celebrity problem. Show the hybrid solution. This is what interviewers want to hear.

3. Feed cache numbers -- "500M users x 500 posts x 30 bytes = 7.5 TB in Redis. With eviction of inactive users, ~2 TB. That's ~30-40 Redis nodes." Shows you can do the math.

4. Image processing is important but brief -- "Upload directly to S3 via presigned URL. Process async: resize to 5 versions. Store all in S3. Serve via CDN." That's 3 sentences and covers it.

5. Don't forget the social graph -- "The follows table has 100B rows. We shard by follower_id for 'who do I follow' queries and maintain a reverse index for 'who follows me' for fanout."

6. CDN is critical -- "50B image views/day at 200 KB each = 10 PB/day. That's CDN territory. 95%+ cache hit rate because images are immutable."

7. Cursor pagination, not offset -- If feed pagination comes up, explain why cursor-based pagination is stable under concurrent writes. This is a detail that shows real system experience.

8. Ranked feed shows ML awareness -- "Instagram's feed isn't chronological. We rank by interest, recency, relationship, and engagement velocity. Two-stage pipeline: 500 candidates from cache, then ML ranking."

9. Scale numbers anchor the design -- "100M uploads/day = 1,160/sec. 5B feed reads/day = 58K RPS. Read:write is 50:1. This is a read-heavy system, which is why we pre-compute feeds."

10. Stories are a nice add-on -- "Stories are ephemeral posts with a 24-hour TTL. Redis with auto-expire. Separate from the main feed. Show as horizontal tray sorted by recency." Quick, clean, shows breadth.