Bird
Raised Fist0

Instagram - Photo Upload, Feed, Stories, Explore

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Design Instagram - Photo Upload, Feed, Stories, Explore
45 min · senior
senior

You are designing Instagram for a startup with 50 million daily active users (DAU). The system must support photo uploads, personalized feed generation, ephemeral stories, and an explore section with trending content. The system must ensure end-to-end encryption for user data, deliver feed and stories with P99 latency under 200ms, and support offline content delivery for stories. The system should handle peak loads gracefully and scale horizontally.

Constraints
  • End-to-end encryption of user photos and stories at rest and in transit
  • Offline delivery support for stories with eventual consistency
  • Feed and stories P99 latency under 200ms globally
  • Support 50M DAU with peak upload rates of 10K photos/sec
  • Explore section must update trending content every 5 minutes
  • Data retention policies require stories to expire after 24 hours
📋
Guided Steps
1/5
Step 1
Designing the Photo Upload Pipeline
How would you design the photo upload flow to handle 10K uploads/sec with encryption and durability?
💡 Hint
Consider using a distributed object store with client-side encryption and asynchronous processing.
Key Decision
Use AWS S3 with client-side encryption (e.g., AWS KMS) for durable storage and Kafka with user_id partition key for asynchronous processing of metadata and thumbnails.
Interviewer Expectation
Mid: Names S3 and Kafka for storage and messaging. Senior: Explains client-side encryption to ensure end-to-end security and why server-side encryption alone is insufficient at scale.
⚠️Common Wrong Answer
Uploading directly to a relational DB causes bottlenecks and high latency under 10K uploads/sec.
Step 2
Feed Generation and Personalization
How would you design the feed generation system to deliver personalized feeds with P99 latency under 200ms?
💡 Hint
Think about precomputing feeds vs. real-time aggregation and the choice of database for fast reads.
Key Decision
Use a hybrid approach with Apache Cassandra using user_id as partition key for storing user timelines (precomputed feeds) and Apache Spark Streaming for real-time updates and ranking.
Interviewer Expectation
Mid: Mentions Cassandra for timeline storage. Senior: Explains why Cassandra’s wide-column model with user_id partition key enables O(1) range scans and why real-time Spark jobs improve freshness without latency spikes.
⚠️Common Wrong Answer
Using relational DB joins for feed generation leads to high latency and poor scalability.
Step 3
Designing Stories with Offline Delivery and Expiry
How would you design the ephemeral stories feature supporting offline viewing and automatic expiry after 24 hours?
💡 Hint
Consider data TTL, CDN caching, and client-side storage for offline access.
Key Decision
Use Redis with TTL for story metadata, CDN (e.g., CloudFront) for caching encrypted story media, and local encrypted storage on the client for offline viewing.
Interviewer Expectation
Mid: Names Redis TTL and CDN caching. Senior: Explains how Redis TTL enforces expiry, CDN reduces latency globally, and client-side encrypted cache enables offline access without compromising security.
⚠️Common Wrong Answer
Storing stories only in the database without TTL causes storage bloat and stale content.
Step 4
Explore Section and Trending Content Updates
How would you design the explore section to update trending content every 5 minutes efficiently?
💡 Hint
Think about batch processing and caching layers for fast global reads.
Key Decision
Use Apache Flink for streaming analytics to compute trending content every 5 minutes and Redis as a global cache for low-latency reads.
Interviewer Expectation
Mid: Mentions batch jobs for trending. Senior: Explains Flink’s low-latency streaming aggregation and Redis’s role in serving millions of global requests under 200ms P99.
⚠️Common Wrong Answer
Recomputing trending content on every request causes high CPU and latency spikes.
Step 5
API Design for Core User Interactions
Sketch the API design for photo upload, feed retrieval, and story posting endpoints.
💡 Hint
Focus on request/response structure, authentication, pagination, and idempotency.
Key Decision
Design RESTful endpoints with OAuth2 authentication: POST /photos with multipart upload and idempotency keys, GET /feed with cursor-based pagination, POST /stories with TTL metadata and client-generated encryption keys.
Interviewer Expectation
Mid: Defines basic REST endpoints with auth. Senior: Details idempotency for uploads, cursor pagination for feed, and encryption key exchange for stories.
⚠️Common Wrong Answer
Using simple offset pagination causes inconsistent feed results and poor performance at scale.
🔌
API Design Challenge
Sketch 3 core API endpoints for Instagram: photo upload, feed retrieval, and story posting.
Hints
  • How does the client securely upload photos and confirm upload success?
  • How does the client fetch a personalized feed efficiently with pagination?
  • How does the client post ephemeral stories and sync story views?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of client-side encryption for photo uploads to meet end-to-end encryption constraint
  • Feed storage in Cassandra with user_id partition key for scalable, low-latency reads
  • Stories stored with TTL in Redis and cached via CDN for offline delivery and expiry
  • Streaming analytics (Spark/Flink) for real-time feed updates and trending content
Good to Have - 30%
  • Idempotency keys in upload API to handle retries without duplication
  • Cursor-based pagination in feed API for consistent and efficient scrolling
  • Use of Kafka for asynchronous metadata processing and event ordering
Bonus - 10%
  • Client-side encrypted local cache for offline story viewing
  • Detailed API design including authentication and encryption key exchange
Anti-patterns to Avoid
Directly storing photos in relational databases causes severe write bottlenecks and high latency under 10K uploads/sec
Using offset-based pagination in feed leads to inconsistent results and poor performance at scale due to shifting data and duplicates
Recomputing trending content on every request causes high CPU usage and latency spikes, violating SLA
Ignoring TTL for stories leads to storage bloat and stale content exposure, increasing cost and privacy risks
Server-side only encryption without client-side keys risks data exposure if servers are compromised by attackers
Polling-based feed updates cause excessive load and degrade P99 latency under 200ms SLA due to frequent redundant requests
✅
Model Answer
▼ Reveal

The system uses client-side encrypted AWS S3 for photo storage, Kafka with user_id partitioning for metadata processing, Apache Cassandra with user_id partition key for feed storage, Redis with TTL for ephemeral stories, CDN caching for global media delivery, Apache Spark Streaming and Flink for real-time feed and trending content updates, and RESTful APIs with OAuth2, idempotency keys, and cursor-based pagination for secure and efficient client interactions.

Key Decisions
  • Use AWS S3 with client-side encryption (AWS KMS) to ensure end-to-end encryption and durability of photos
  • Partition Kafka topics by user_id to guarantee ordered, scalable processing of photo metadata and thumbnails
  • Store user feeds in Apache Cassandra with user_id as partition key to enable O(1) range scans and low-latency reads at 50M DAU scale
  • Leverage Apache Spark Streaming to update feeds in near real-time without violating 200ms P99 latency SLA
  • Use Redis with TTL to enforce automatic expiry of ephemeral stories after 24 hours
  • Cache encrypted story media in CDN (CloudFront) to reduce latency globally and support offline access
  • Compute trending content every 5 minutes using Apache Flink streaming analytics for efficient, scalable updates
  • Design RESTful APIs with OAuth2 authentication, idempotency keys for photo uploads, and cursor-based pagination for feed retrieval to ensure secure, consistent client interactions
  • AWS S3 with client-side encryption ensures durable, secure photo storage preventing server-side key exposure
  • Kafka partitions keyed by user_id for metadata processing guarantee ordered, scalable event handling
  • Apache Cassandra with user_id partition key enables O(1) range scans for fast feed retrieval at 50M DAU scale
  • Apache Spark Streaming updates feeds in near real-time without violating 200ms P99 latency SLA
  • Redis with TTL enforces automatic story expiry and supports ephemeral data semantics
  • CDN caching (CloudFront) reduces latency for global story media delivery and supports offline access
  • Apache Flink streaming analytics computes trending content every 5 minutes efficiently at scale
  • RESTful APIs with OAuth2, idempotency keys, and cursor-based pagination ensure secure, consistent client interactions

Practice

(1/5)
1. A company needs to store large amounts of unstructured data like images and videos with metadata accessible via HTTP APIs. Which storage type best fits this use case?
easy
A. Object storage, because it stores data as objects with metadata and supports HTTP access.
B. Block storage, because it provides low-latency random access to raw data blocks.
C. File storage, because it offers hierarchical directories and POSIX file system semantics.
D. In-memory storage, because it offers the fastest access to large files.

Solution

  1. Step 1: Identify storage needs for unstructured data with metadata

    Object storage stores data as objects with customizable metadata and supports HTTP APIs, ideal for images/videos.

  2. Step 2: Eliminate other storage types

    Block storage is low-level and lacks metadata support; file storage is optimized for hierarchical file systems but less scalable for massive unstructured data; in-memory storage is volatile and unsuitable for large persistent files.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Object storage = scalable unstructured data + metadata + HTTP [check]
Hint: Object storage = objects + metadata + HTTP access [check]
Common Mistakes:
2. In the request flow of a video call setup, at step 5 the Signaling Server receives an SDP offer from Alice and forwards it to Bob. What state does the Signaling Server maintain immediately after forwarding the offer?
easy
A. It stores the offer and waits for Bob's SDP answer before updating session state
B. It queues the offer indefinitely until Bob acknowledges receipt
C. It deletes the offer after forwarding, assuming Bob will respond directly to Alice
D. It marks the session as established and starts media relay between Alice and Bob

Solution

  1. Step 1: Trace Signaling Server behavior at step 5

    The server forwards Alice's SDP offer to Bob and stores it to correlate with Bob's answer.

  2. Step 2: Understand session state management

    Session is not established until Bob's SDP answer arrives; the offer must be retained temporarily.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Signaling Server stores offer awaiting answer before session established [check]
Hint: Signaling stores offer until answer arrives, then session established [check]
Common Mistakes:
3. In the timeline generation flow, at step 4 the Delivery Worker reads from Kafka and checks the follower's timeline cache TTL. What happens if the cache TTL has expired for a follower at this step?
easy
A. The Delivery Worker triggers a timeline rebuild for that follower before delivering
B. The Delivery Worker retries reading the cache until TTL refresh completes
C. The Delivery Worker writes the tweet directly to the follower's timeline DB without cache refresh
D. The Delivery Worker skips the follower and marks the message as delivered

Solution

  1. Step 1: Understand Delivery Worker cache TTL check

    If TTL expired, the cached timeline is stale and must be rebuilt to ensure fresh data.

  2. Step 2: Evaluate actions on expired TTL

    Skipping (A) loses data; direct DB write (C) bypasses cache rebuild; retrying cache read (D) causes blocking and delays.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired TTL triggers timeline rebuild to maintain freshness [check]
Hint: Expired cache TTL triggers timeline rebuild [check]
Common Mistakes:
4. For a global social media platform with highly skewed user activity, which sharding strategy best balances load while minimizing cross-shard queries?
medium
A. Directory-based sharding to assign hot users to dedicated shards dynamically
B. Hash-based sharding to evenly distribute users regardless of activity
C. Range-based sharding to group users by geographic region
D. Random sharding to avoid hotspots by unpredictable distribution

Solution

  1. Step 1: Analyze skew and query patterns

    Skewed activity causes hotspots; static range or hash sharding can't adapt dynamically.

  2. Step 2: Evaluate strategies

    Directory-based sharding allows dynamic assignment of hot users to dedicated shards, balancing load and reducing cross-shard queries.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Directory-based sharding supports dynamic load balancing [check]
Hint: Directory sharding adapts dynamically to hotspots [check]
Common Mistakes:
5. If the global BGP route monitoring system is disabled during a misconfiguration event, what is the most likely failure observed in the network recovery process?
medium
A. Routers automatically revert to default static routes, causing traffic blackholing
B. Network devices silently drop BGP updates, leading to partial route visibility
C. Operators receive delayed alerts, causing prolonged outage and inconsistent routing states
D. Clients experience immediate failover to backup ISPs without disruption

Solution

  1. Step 1: Role of BGP monitoring

    BGP monitoring detects anomalies and route changes; without it, routers may silently drop updates due to misconfigurations.

  2. Step 2: Eliminate other options

    Delayed alerts (A) affect operators but don't cause silent drops; routers don't revert to static routes automatically (B); immediate client failover (D) unlikely without proper routing.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without monitoring, routers drop BGP updates silently causing partial visibility [check]
Hint: No monitoring -> silent BGP update drops, partial routes [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