Design a Photo-Sharing Feed
like Instagram

"Design Instagram" is a canonical FAANG question because it compresses three fundamentally different hard problems into one: a high-throughput binary data pipeline (images), a social graph traversal problem (who follows whom), and a personalized feed assembly problem (what to show, in what order). Solving any one of them is straightforward. Solving all three while keeping latency under 200ms is the interview.

The question "design Instagram" is deliberately vague. Scoping it correctly — and explaining why you scoped it this way — is itself part of the evaluation. Start here before touching architecture.

Functional requirements

Non-functional requirements

NFR reasoning

Instagram's load profile is dramatically read-heavy. For every photo uploaded, it's viewed hundreds to thousands of times. The write path (uploads) is a relatively thin stream; the read path (feed loads, profile views, photo fetches) is the scale challenge to design for. Image data adds a critical second dimension: storage and bandwidth numbers dwarf what you'd see in a text-only system.

The architecture splits cleanly into three planes. The upload plane handles inbound binary data: client → object store → processing pipeline → metadata write. The read plane handles feed and photo delivery: client → CDN → feed cache → API servers → database for cache misses. The social graph plane manages follow relationships and drives the feed fan-out process that connects uploads to reads. A durable message queue (Kafka) decouples all three.

Component breakdown

CDN (content delivery network) sits in front of all photo delivery. It caches the three image variants (thumbnail, feed-resolution, full-resolution) at edge nodes globally. Once a photo is cached at a PoP, subsequent requests for that URL cost zero origin bandwidth. For a platform with billions of daily photo fetches, CDN cache hit rates ≥90% are the difference between a viable and an unviable bandwidth bill.

API Gateway / Load Balancer is the single entry point for all non-image traffic: authentication token validation, rate limiting (per-user and per-IP), and routing to the three service clusters (Upload API, Feed API, Social API). It does not handle image bytes — those go directly from the client to object storage via pre-signed URL.

Upload API handles the upload initiation flow. On a POST /photos/upload request, it validates the request, generates a pre-signed URL pointing at object storage (S3), and returns it to the client. The client then uploads the binary data directly to S3 without touching the Upload API server again. After the S3 upload completes, the client notifies the Upload API, which writes a pending record to the Post DB and enqueues a processing job. This architecture keeps multi-hundred-KB binary data off the application tier entirely.

Image Processor is a stateless worker pool that consumes from an object-store event trigger (S3 event notification or SQS queue). For each uploaded photo, it generates three resolution variants — thumbnail (150×150px), feed resolution (640×640px), and full resolution (1080×1080px) — and writes them back to object storage with stable, CDN-friendly URLs. Once processing completes, it writes the final CDN URLs to the Post DB and publishes a post.published event to Kafka.

Feed API assembles the home feed for a requesting user. It first checks the user's pre-computed feed list in the Redis Feed Cache. On a cache hit, it hydrates post metadata (cached separately) and returns the response. On a miss (new user, cache evicted, or first request), it falls back to a database fan-in query: fetch the user's followed list from Graph DB, query Post DB for recent posts from each followee, merge and sort. Cache misses are expensive but rare in steady state. Hydration avoids N+1: metadata for all ~20 posts in a page is fetched in a single Redis pipeline (MGET post:{id1} post:{id2} … or pipelined HGETALL calls) rather than 20 serial round-trips. Cache misses within the batch trigger a parallel async read from Cassandra, with results written back to Redis before the response returns.

Social API manages the follow graph: creating and deleting follow relationships, returning follower/following counts, and handling the Graph DB writes that trigger fan-out. When a user follows someone, the Graph DB record is written synchronously; feed cache updates happen asynchronously.

Post DB (wide-column store, Cassandra) stores post metadata: photo ID, user ID, CDN URLs for all three variants, caption, timestamp, like count (approximate), comment count. Cassandra's append-friendly write path handles the high upload write rate without locking. Reads are by (user_id, time_range), which maps cleanly to Cassandra's partition + clustering key model.

Graph DB (relational, PostgreSQL or sharded MySQL) stores the follow graph as a follows table with (follower_id, followee_id, created_at). Both directions are indexed because the system needs to answer both "who do I follow?" (write fan-out) and "who follows me?" (notification). At very large scale (billions of edges), this migrates to a dedicated graph service (Meta's TAO), but for interview purposes a sharded relational store is the correct starting point.

Feed Cache (Redis sorted sets) holds one per-user sorted set of post IDs, ordered by timestamp. Each post_id maps to a post metadata hash. The Fan-out Worker appends new post IDs to followers' sorted sets; Feed API pops the top N. TTL is set to avoid stale feed eviction — active users will have their caches refreshed frequently; inactive users' caches expire and are rebuilt on next login.

Kafka event pipeline receives post.published events from the Image Processor and follow.created events from the Social API. The Fan-out Worker subscribes and executes the feed propagation logic. The Notification Service subscribes to the same stream for independent like and follow notifications. This decoupling means a slow fan-out for a celebrity post doesn't delay photo processing or the API response.

Notification Service is a separate stateless consumer group on Kafka that processes post.published, like.created, and follow.created events. For each event, it resolves the target user's push token (APNs for iOS, FCM for Android) from a Device Registry store and enqueues a push notification via the respective platform gateway. Two reliability constraints matter here: (1) at-least-once delivery: Kafka consumer group commit-after-ack ensures no notification is silently dropped on worker crash; (2) deduplication — if a post triggers fan-out to 10,000 followers and the worker retries, the same notification must not be sent twice. A Redis set (notif_sent:{event_id}:{user_id}, TTL 24 h) acts as an idempotency gate before the push is dispatched. In-app notifications are written to a notifications table and fetched on app open — no real-time socket needed for the baseline design. (Scale note: at 500 M DAU a Cassandra table — notifications_by_user, partitioned by recipient_user_id, clustered by created_at DESC — handles concurrent per-user appends more efficiently than a PostgreSQL table, which requires explicit partitioning by user_id to avoid hot-row contention at this write rate.)

Fan-out Worker is a horizontally scalable consumer pool that receives post.published events and decides whether to push (regular user) or skip (celebrity — readers will pull). For push-eligible posts, it reads the poster's follower list from Graph DB in paginated batches and writes the post ID to each follower's Redis sorted set via a pipeline command. The worker itself is stateless; Kafka consumer group semantics handle parallel processing across workers.

Architectural rationale

Real-world comparison

Before designing the feed read path, you have to answer a fundamental question: when a user posts a photo, when does that photo enter their followers' feeds — at write time or at read time? This single decision drives the fan-out architecture, the feed latency design, the Redis data model, and the special handling for celebrity accounts.

The tension is simple: making feeds fast to read (pre-computed) makes posts expensive to write (must update millions of feed caches). Making posts cheap to write (store once) makes feed reads expensive (must dynamically assemble from scratch). Neither extreme works at Instagram scale. Two pure approaches and one hybrid dominate the space.

Our choice for this system: Use the hybrid fan-out (③). Posts from users with fewer than ~10,000 followers are pushed to all follower feed caches asynchronously within seconds. Posts from celebrity accounts (above threshold) are stored once in the Post DB. When reading the feed, the Feed API merges the user's pre-computed push cache with a fresh pull of the latest N posts from each celebrity they follow, then sorts by timestamp before applying ranking. The merge is a simple N-way merge of sorted lists — efficient even for users who follow dozens of celebrities.

# Fan-out worker (pseudocode)
def handle_post_published(event):
    post_id   = event['post_id']
    poster_id = event['user_id']

    # Check if poster is celebrity (cached in Redis)
    follower_count = get_cached_follower_count(poster_id)

    if follower_count <= CELEBRITY_THRESHOLD:  # e.g. 10,000
        # Fan-out-on-write: push to all followers in batches
        fan_out_to_followers(poster_id, post_id)
    # else: celebrity — no fan-out; pulled at read time

def fan_out_to_followers(poster_id, post_id):
    page_token = None
    while True:
        followers, next_token = get_followers_page(poster_id, page_token)
        # Redis pipeline: ZADD feed:{follower_id} score=timestamp post_id
        with redis.pipeline() as pipe:
            for fid in followers:
                pipe.zadd(f'feed:{fid}', {post_id: event['ts']})
                # Trim batched with ZADD in same pipeline (single round-trip); no-op if set < MAX_FEED_SIZE
                pipe.zremrangebyrank(f'feed:{fid}', 0, -(MAX_FEED_SIZE+1))
            pipe.execute()
        if not next_token: break
        page_token = next_token

# Feed read: merge push cache + celebrity pulls
def get_home_feed(user_id, page_size=20):
    # Step 1: get pre-computed feed from Redis (cursor-aware)
    # Use ZREVRANGEBYSCORE with the cursor timestamp as upper-bound score — not ZREVRANGE by rank.
    # ZREVRANGE offsets shift as new posts are prepended, causing duplicate/skipped items on page 2+.
    max_score = cursor_ts if cursor_ts else '+inf'
    pushed = redis.zrevrangebyscore(f'feed:{user_id}', max_score, '-inf', start=0, num=page_size * 3)

    # Step 2: pull latest posts from followed celebrities
    celebrities = get_followed_celebrities(user_id)
    pulled = [get_recent_posts(c_id, n=10) for c_id in celebrities]

    # Step 3: merge + sort + rank + truncate
    candidates = merge_sorted(pushed, *pulled)
    return rank_and_truncate(candidates, page_size)

Two endpoints dominate the hot path: the upload initiation endpoint and the feed read endpoint. Both are called from mobile clients where latency is compounded by cellular network variability.

POST /photos — initiate upload

Returns a pre-signed URL for direct-to-S3 upload. The actual binary data never flows through this endpoint. Using PUT (not POST) to S3 because S3 pre-signed URLs for object creation use PUT semantics. The client is responsible for following up with POST /photos/{id}/complete after the S3 upload finishes.

// Request
{
  "filename": "IMG_2047.HEIC",
  "content_type": "image/heic",
  "size_bytes": 4721038,
  "caption": "Sunset at Big Sur 🌅",
  "location": { "lat": 36.27, "lon": -121.81 },
  "tags": ["#sunset", "#california"]
}

// Response 200 OK (pre-signed URL for direct S3 upload)
{
  "photo_id": "ph_8Xk2mNqLp9vW",
  "upload_url": "https://s3.amazonaws.com/ig-uploads/ph_8Xk2mNqLp9vW?X-Amz-Signature=...",
  "upload_method": "PUT",
  "upload_headers": {
    "Content-Type": "image/heic",
    "Content-Length": "4721038"
  },
  "expires_at": "2026-04-24T21:15:00Z"  // 15-min window
}

POST /photos/{id}/complete — finalize after upload

// Request (no body required — server validates S3 object existence)

// Response 202 Accepted (processing async)
{
  "photo_id": "ph_8Xk2mNqLp9vW",
  "status": "processing",
  "estimated_ready_ms": 4000,
  "poll_url": "/photos/ph_8Xk2mNqLp9vW/status"
}

// GET /photos/{id}/status — once processing completes:
{
  "photo_id": "ph_8Xk2mNqLp9vW",
  "status": "published",
  "urls": {
    "thumbnail": "https://cdn.intervu.dev/ph_8Xk2mNqLp9vW/t.jpg",
    "feed": "https://cdn.intervu.dev/ph_8Xk2mNqLp9vW/f.jpg",
    "full": "https://cdn.intervu.dev/ph_8Xk2mNqLp9vW/o.jpg"
  },
  "published_at": "2026-04-24T20:58:34Z"
}

GET /feed — home feed

Cursor-based pagination (no offset). The cursor encodes the last-seen timestamp so subsequent pages are stable even as new posts arrive. Returns metadata only — image bytes are fetched separately by the client via CDN URLs. Request validates authentication via bearer token in the Authorization header.

// Request: GET /feed?limit=20&cursor=eyJ0cyI6MTc0NTUzMTg5Mn0

// Response 200 OK
{
  "posts": [
    {
      "post_id": "ph_8Xk2mNqLp9vW",
      "user": {
        "user_id": "u_4Rm9pXzL",
        "username": "juanita.m",
        "avatar_url": "https://cdn.intervu.dev/avatars/u_4Rm9pXzL.jpg"
      },
      "caption": "Sunset at Big Sur 🌅",
      "image_urls": {
        "thumbnail": "https://cdn.intervu.dev/ph_8Xk2mNqLp9vW/t.jpg",
        "feed": "https://cdn.intervu.dev/ph_8Xk2mNqLp9vW/f.jpg"
      },
      "like_count": 1842,
      "comment_count": 37,
      "liked_by_viewer": false,
      "created_at": "2026-04-24T20:58:34Z"
    }
  ],
  "next_cursor": "eyJ0cyI6MTc0NTQ4NjIxMH0",
  "has_more": true
}

Two flows dominate the system. The upload flow is write-critical and must preserve every photo; the feed read flow is latency-critical and must return in under 200ms. They interact through Kafka: the upload flow publishes events; the feed read flow consumes pre-built caches that the fan-out worker produced from those events.

Upload flow

Feed read flow

The data model has three distinct domains — posts, users/graph, and engagement (likes, comments) — each with very different access patterns. Those differences end up shaping which store each entity lives in and how it's keyed.

Access patterns

Two things jump out from this table. First, the post read path is predominantly by (user_id, time) for profile grids and by (post_id) for feed hydration — two different primary access patterns that suggest two indexes. Second, like counts and "has viewer liked" are read on every feed render; they must be precomputed, not computed on-the-fly from a likes table at read time.

Schema

The caching architecture for Instagram has four distinct layers, each positioned at a different tier of the §4 architecture. Without each layer, a different latency or cost ceiling is hit. The layers are not redundant — they address different bottlenecks.

Cache invalidation

At 500 M DAU, the production Instagram architecture must handle several failure modes and scale pressures that don't appear at smaller scale. This section traces through the five key scalability dimensions that L5+ candidates are expected to address.

Three security concerns map directly to components already in the architecture: abuse prevention on the upload path, illegal content detection in the image pipeline, and regulatory erasure requirements that span every storage tier. L6+ interviewers will probe all three explicitly.

Upload rate limiting

Without rate limiting, a single malicious client can exhaust S3 pre-signed URL generation capacity and drive disproportionate storage write cost. The API Gateway enforces a per-user token-bucket rate limit on POST /photos: maximum 10 uploads per minute per authenticated user, enforced via a Redis counter (INCR ratelimit:{user_id}:{minute_bucket} with a 60-second TTL). Requests exceeding the limit receive a 429 Too Many Requests response with a Retry-After header. A separate, higher limit (100/min) applies at the IP level to catch unauthenticated probing before authentication succeeds.

Perceptual hash deduplication and content moderation

The Image Processor runs two checks before writing variants to S3:

1. Exact-hash deduplication: SHA-256 of the raw upload is checked against a probabilistic hash store (e.g., a disk-backed bloom filter or a Redis SET of known hashes) of previously stored object hashes. Bit-exact duplicates skip variant generation and reuse existing CDN URLs. Important: a bloom filter has no false negatives but can produce false positives — a false positive would silently deduplicate a genuinely unique image against someone else's photo. The implementation must include a fallback verification step: before reusing a CDN URL, confirm the candidate S3 object exists and its SHA-256 matches the new upload's hash. At 100 M uploads/day over 10 years (~365 B cumulative), a bloom filter targeting ≤0.001% false-positive rate requires ~5 GB of RAM — size accordingly.
2. Perceptual hash (pHash / PhotoDNA): The processor computes a perceptual hash of the image and checks it against a blocklist of known-illegal content hashes (CSAM, jurisdiction-required blocklists). A match aborts the job, tombstones the S3 object, and triggers a moderation queue entry. This check happens before any variant is written publicly: the image never reaches CDN. The blocklist is a small in-memory set (≤100 MB) loaded at worker startup and refreshed hourly.

GDPR right-to-erasure pipeline

A user deletion request triggers a multi-stage erasure job implemented as a durable workflow (e.g., AWS Step Functions) to survive partial failures. The pipeline must reach every storage tier:

Classic probes