Bird
Raised Fist0

Instagram - Photo Upload, Feed, Stories, Explore

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Instagram - Photo Upload, Feed, Stories, Explore
Design Instagram's core features focusing on photo upload, feed generation, stories, and explore at 2B DAU scale
hardSocial Media and Feed SystemsFreq: high
Prerequisites:System Design FundamentalsCAP TheoremDistributed SystemsData Modeling for Social MediaCaching and CDN Strategies
⚙️
Functional Requirements
  • Users can upload photos and videos with metadata (caption, location, tags).
  • Generate personalized home feed showing posts from followed users in reverse chronological or ranked order.
  • Support ephemeral Stories feature with 24-hour expiry and rich media.
  • Explore tab to show trending and recommended content based on user interests and global popularity.
  • Like, comment, and share interactions on posts and stories.
  • Push notifications for new posts, stories, and interactions.
📊
Non-Functional Requirements
  • Support 2 billion daily active users (DAU).
  • Handle peak write throughput of ~925K photo/video uploads per second.
  • Feed generation and story retrieval latency under 100ms P99.
  • System availability of 99.99% (less than ~52 minutes downtime per year).
  • Data durability with replication and backups to prevent data loss.
❓
Clarifying Questions to Ask
  • What is the average size of photos and videos uploaded?
  • Are stories stored differently from regular posts in terms of retention and access patterns?
  • What is the expected read-to-write ratio for feed and explore requests?
  • Should the feed be strictly chronological or ranked by relevance?
  • What is the expected retention period for posts and stories?
  • Are there any regional data residency or compliance requirements?
Out of Scope
✗ Direct messaging and chat features.
✗ Video live streaming and IGTV long-form video.
✗ Ads and monetization infrastructure.
✗ User authentication and account management.
📌
Assumptions
  • 2 billion DAU
  • Average 40 photo/video uploads per user per day (including stories and posts)
  • Average media size 100 KB per upload (compressed photo/video thumbnail)
  • Retention period for posts: 1 year; stories: 24 hours
  • Replication factor: 3 for durability
⚡
QPS Calculation
write qps2B users × 40 uploads/day ÷ 86400 seconds ≈ 925,926 writes/sec
peak write qpsAssuming 3× peak factor during prime hours: 925,926 × 3 ≈ 2.78M writes/sec
read qpsAssuming 20 feed reads per user per day: 2B × 20 ÷ 86400 ≈ 462,963 reads/sec
💾
Storage Estimate
daily storage2B × 40 × 100 KB = 8 PB/day uncompressed
daily storage compressedAssuming 50% compression: 4 PB/day
retention storage4 PB/day × 365 days = 1.46 EB for posts
stories storage2B × 10 stories/day × 100 KB × 1 day = 2 PB (ephemeral)
total storage with replication(1.46 EB + 2 PB) × 3 = ~4.4 EB
🖥️
Server Estimate
media storage nodesAssuming 100 TB per node, need ~44,000 nodes for replicated storage
feed generation serversAssuming each server handles 10K QPS, need ~46,000 servers for peak read QPS
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |  User App   |
          +------+------+
                 | Upload/Read Requests
          +------+------+
          | API Gateway |
          +------+------+
                 |
    +------------+-------------+
    |                          |
 +--v---+                  +---v---+
 | Auth |                  | Upload|
 | Svc  |                  | Svc   |
 +--+---+                  +---+---+
    |                          |
    |                          |
 +--v--------------------------v---+
 |       Media Storage (S3 + CDN)   |
 +----------------------------------+
    |                          |
 +--v---+                  +---v---+
 | Feed |                  | Stories|
 | Gen  |                  | Svc    |
 +--+---+                  +---+---+
    |                          |
 +--v--------------------------v---+
 |       NoSQL DB (Cassandra)       |
 +----------------------------------+
                 |
          +------+------+
          | Explore Svc |
          +-------------+
🧩
Components
API Gateway
Entry point for all client requests, routes to appropriate backend services
Why thisNginx with Envoy proxy for high throughput, low latency, and dynamic routing
Why notAWS ALB lacks fine-grained routing and observability at 2B DAU scale
Upload Service
Handles photo/video upload, metadata extraction, and validation
Why thisStateless microservice in Kubernetes for horizontal scaling and fault isolation
Why notMonolithic backend would bottleneck and complicate deployments at 925K writes/sec
Media Storage (S3 + CDN)
Stores raw media files and serves them via CDN for low latency global access
Why thisAmazon S3 for durable, scalable object storage + CloudFront CDN for caching near users
Why notHDFS lacks global distribution and CDN integration, causing high latency
Feed Generation Service
Generates personalized feeds by aggregating followed users' posts and ranking them
Why thisApache Kafka + Apache Flink for real-time stream processing and ranking at scale
Why notBatch processing with Hadoop is too slow for 100ms P99 latency requirements
Stories Service
Manages ephemeral stories with 24-hour TTL and fast retrieval
Why thisRedis with TTL for ephemeral data and Cassandra for durable metadata storage
Why notMemcached lacks persistence and TTL management, risking data loss
NoSQL Database (Cassandra)
Stores user posts, metadata, feed state, and interaction data with high write throughput
Why thisCassandra supports linear write scalability, tunable consistency, and multi-datacenter replication
Why notPostgreSQL requires complex manual sharding and cannot handle 2.78M writes/sec
Explore Service
Recommends trending and personalized content using ML models and global popularity metrics
Why thisTensorFlow Serving + Redis for low-latency model inference and caching
Why notOn-demand model inference without caching causes high latency and poor UX
Authentication Service
Validates user identity and issues tokens for secure API access
Why thisOAuth 2.0 with JWT tokens for stateless, scalable authentication
Why notSession-based auth does not scale well for 2B DAU and complicates horizontal scaling
🔄
Data Flow
1
User App → API Gateway
User uploads photo/video with metadata
API Gateway routes upload request to Upload Service
2
Upload Service → Media Storage
Stores media file in S3 and caches via CDN
Upload Service stores metadata in Cassandra
3
Upload Service → Feed Generation Service
Publishes new post event to Kafka topic
Triggers feed update for followers
4
Feed Generation Service → NoSQL DB (Cassandra)
Updates followers' feed timelines with new post references
Uses Flink for real-time ranking and aggregation
5
User App → API Gateway
User requests home feed or stories
API Gateway routes to Feed or Stories Service
6
Feed/Stories Service → NoSQL DB + Media Storage
Fetches feed metadata and media URLs
Stories Service uses Redis TTL for ephemeral data
7
Explore Service → User App
Serves personalized explore content
Uses ML models cached in Redis for low latency

Practice

(1/5)
1. Without the retry queue component in the payment gateway's webhook delivery system, what exact failure occurs when a merchant's endpoint is temporarily down?
medium
A. Webhook notifications are retried immediately in a tight loop, overwhelming the merchant server
B. Webhook delivery blocks the main payment processing thread until the merchant recovers
C. Webhook notifications are queued in memory indefinitely, causing memory leaks and crashes
D. Webhook notifications are lost permanently with no retry, causing inconsistent merchant state

Solution

  1. Step 1: Understand retry queue role

    The retry queue buffers failed webhook notifications for asynchronous retries, ensuring eventual delivery.

  2. Step 2: Consequence of missing retry queue

    Without it, failed webhooks are dropped or lost, causing permanent notification loss and inconsistent merchant state.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Missing retry queue -> permanent webhook loss on failure [check]
Hint: Retry queue prevents permanent webhook loss [check]
Common Mistakes:
2. Given the need for zero data loss during failover and minimal downtime, which architecture is best suited for GitHub's database cluster?
medium
A. Asynchronous replication with delayed failover to reduce load
B. Read-only replicas with manual failover triggered by monitoring
C. Multi-master replication with eventual consistency
D. Synchronous replication with consensus-based leader election

Solution

  1. Step 1: Evaluate replication and failover requirements

    Zero data loss requires synchronous replication; minimal downtime requires automated leader election.

  2. Step 2: Compare architectures

    Asynchronous replication (A) risks data loss; multi-master (C) complicates consistency; manual failover (D) increases downtime.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Synchronous replication + consensus election ensures data safety and fast failover [check]
Hint: Synchronous replication ensures no data loss during failover
Common Mistakes:
3. If the API Gateway's rate limiting cache fails and is not replaced, what is the immediate failure mode observed by users?
medium
A. Users receive explicit rate limit errors even when under limit
B. Requests bypass rate limiting, causing backend overload and degraded service
C. The system automatically switches to database-level rate limiting with no impact
D. All requests are silently dropped without response

Solution

  1. Step 1: Understand cache failure impact

    Without the cache, the API Gateway cannot track usage accurately, often defaulting to conservative rate limit errors to protect backend.

  2. Step 2: Evaluate other options

    Silent drops cause user confusion; bypassing limits risks overload; automatic fallback to DB rate limiting is rare and slow.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Cache failure -> conservative rate limit errors -> user impact [check]
Hint: Cache failure triggers conservative rate limit errors [check]
Common Mistakes:
4. At 10x scale, which component in the blob store architecture is most likely to fail first due to stateful connection limits, and why?
hard
A. Front-end API servers, because they maintain stateful client sessions and cannot easily shard connections
B. Storage nodes, because disk I/O bandwidth saturates with large blob volumes
C. Metadata service, because it cannot shard metadata fast enough across nodes
D. Distributed log system, because partition leaders become overloaded with write requests

Solution

  1. Step 1: Identify stateful bottleneck at front-end API servers

    API servers maintain stateful client sessions (e.g., HTTP keep-alive or TLS), limiting horizontal scaling due to connection affinity.

  2. Step 2: Eliminate other options

    Storage nodes scale with added disks; metadata service shards metadata; distributed log partitions scale with more brokers.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful client sessions limit API server horizontal scaling [check]
Hint: Stateful API servers limit scaling due to connection affinity [check]
Common Mistakes:
5. At 10x current scale, which component in the Reddit voting and ranking system is most likely to fail first, and why?
hard
A. The relational database storing user profiles, due to increased read queries
B. The ranking service's in-memory cache, because it cannot shard scores by post_id effectively
C. The WebSocket servers maintaining live connections, because stateful connections cannot be resharded easily
D. The Kafka cluster, due to partition leader election delays under heavy load

Solution

  1. Step 1: Analyze stateful vs stateless components at scale

    Relational DB (The relational database storing user profiles, due to increased read queries) can be scaled with read replicas; Kafka (The Kafka cluster, due to partition leader election delays under heavy load) scales well with partitions. Ranking cache (The ranking service's in-memory cache, because it cannot shard scores by post_id effectively) can shard by post_id.

  2. Step 2: Identify WebSocket server bottleneck

    WebSocket servers hold stateful connections bound to server memory; these connections cannot be moved easily, limiting horizontal scaling and causing failures under 10x load.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers fail first due to unshardable live connections [check]
Hint: Stateful WebSocket servers bottleneck at 10x scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard