Designing Instagram: System Design of News Feed

Designing a social media platform like Instagram requires handling massive media storage, complex social graphs (followers), interactive engagement (likes and comments), and real-time newsfeed generation. This chapter breaks down the core feature set, database schema evolution, service-oriented architecture, and optimization strategies for high scale.

1. Core Feature Set & Interview Scope Management

During a system design interview, it is vital to narrow down requirements rather than guessing what to build. Instagram supports numerous features, but interview time constraints require focusing on the fundamental pillars:

• Media Storage & Retrieval: Storing images efficiently and serving them rapidly via Content Delivery Networks (CDNs).
• Liking & Commenting: Engaging with posts and comments through structured database relations.
• Social Graph (Following): Establishing directed edges between users (User A follows User B).
• Newsfeed Publishing: Aggregating and serving a personalized stream of recent posts from followed accounts.

Note: Storing and retrieving images is a foundational problem shared with media-heavy applications like Tinder. Leveraging a distributed file system combined with a CDN solves low-latency media delivery.

2. Database Schema Design: Likes, Comments, and Posts

Designing tables for likes and comments requires handling relational boundaries cleanly. A naive approach can quickly lead to slow queries and dirty schemas.

The Comment and Reply Hierarchy Constraint

Instagram limits comment complexity by design:

• Users can comment on a post.
• Users can reply to a comment (one level deep).
• Instagram does not allow infinite nested replies (replying to a reply to a reply), keeping relational complexity bounded.

Evolving the Like and Comment Schema

Instead of packing aggregation counters (like total_likes) directly into the posts or comments tables—which causes high write contention and violates database normalization—we use a dedicated activity and relations model.

Table Structure Comparison

3. Social Graph: Managing Followers

The follow feature requires answering two fundamental queries:

1. "Who are the people following me?" (Followers list)
2. "Who am I following?" (Following list)

Both directions are easily satisfied using a single Follows Table with two indexed foreign keys: follower_user_id and followee_user_id.

By indexing both columns, queries such as SELECT follower_user_id FROM follows WHERE followee_user_id = 'StephenHawking' execute instantly even at web scale.

4. API Gateway, Reverse Proxy, and Protocol Translation

Since Instagram is primarily a mobile application, requests enter the server architecture through an edge layer.

Key Responsibilities of the Gateway:

• Protocol Translation: Converts public-facing protocols (HTTP, WebSockets via XMPP/STOMP) into internal communication protocols.
• Security Enforcement: Validates authentication tokens at the edge before requests reach internal microservices.
• Traffic Routing: Coordinates with load balancers maintaining system-wide service topology snapshots.

5. Load Balancing & Service Discovery

To achieve high availability and horizontal scalability, multiple instances of internal services (such as the User Feed Service) run concurrently.

• Load Balancer State Snapshots: Instead of querying a central router on every single request, the load balancer maintains a cached snapshot of the entire service topology (service IDs, IP addresses, and health status).
• Periodic Syncing: This snapshot is refreshed every ~10 seconds.
• Consistent Hashing: The gateway applies a consistent hashing algorithm on the user_id parameter to route a user's requests directly to the exact server box holding their active state or cache partition.

6. Naive vs. Optimized Feed Generation (Fan-Out Approaches)

Generating a user's newsfeed involves fetching the top posts from everyone they follow. There are two primary architectural models for solving this: Fan-Out on Read (Pull) and Fan-Out on Write (Push).

Approach A: Fan-Out on Read (Pull Model)

When a user opens their app and requests their feed:

1. Query the Follow Service to get the list of all users they follow (e.g., 500 users).
2. Query the Post Service for each of those 500 users, or execute a complex SQL JOIN across posts.
3. Sort the combined posts by timestamp and return the top 20 items.

The Problem: This approach is computationally expensive. Running complex joins or hundreds of database lookups on the fly for every app open will quickly overwhelm the database and crash the post service.

Approach B: Fan-Out on Write (Push Model)

Instead of computing feeds on read, pre-compute them when posts are created:

1. User X makes a new post.
2. The Post Service persists the post in the database.
3. The Post Service triggers an asynchronous event notifying the User Feed Service.
4. The User Feed Service looks up all followers of User X and pushes/appends this new post_id directly into each follower's pre-computed feed cache.
5. When a user opens Instagram, the app fetches their pre-computed feed in a single O(1) cache lookup.

7. Caching Strategy for User Feeds

Pre-computed feeds must be stored in high-performance in-memory stores like Redis rather than relational databases.

• Memory Management via LRU (Least Recently Used): Because memory is finite, we do not store feeds for inactive users indefinitely.
• Active vs. Inactive Users: If a user logs in frequently, their feed remains warm in the Redis cache. If an inactive user hasn't logged in for months, their feed is evicted from cache to save RAM. When they eventually return, the system falls back to a one-time on-read computation to regenerate their feed and re-cache it.

8. The Celebrity Problem (The Fan-Out Challenge)

When a celebrity with 50 million followers makes a post, the Push (Fan-Out on Write) model breaks down. Pushing a single post ID to 50 million follower caches simultaneously creates a massive write storm ("thundering herd") that can crash the Redis cluster.

Hybrid Fan-Out Architecture

To solve the celebrity problem, systems adopt a Hybrid Model:

• For Normal Users (< 10,000 followers): Use the Push Model. Instantly fan out posts to followers' cached feeds.
• For Celebrities / Public Figures (> 1,000,000 followers): Use the Pull Model. Do not fan out the post to millions of caches. Instead, when a follower views their feed, the system merges posts from their regular following (from cache) with real-time fetches from any followed celebrities.

9. Summary and Key Takeaways

• Clarify First: Never jump straight into building features; always confirm feature sets (media storage, likes, comments, follows, feeds) with the interviewer.
• Polymorphic Relations: Use polymorphic parent types and IDs in unified tables like likes to cleanly support interactions across both posts and comments without schema duplication.
• Bounded Complexity: Keep comment threads simple (e.g., restricted to a single level of replies) to prevent runaway recursive database queries.
• Gateway & Routing: Use an API gateway for reverse proxying, SSL termination, authentication, and protocol translation, coupled with load balancers using consistent hashing.
• Push vs. Pull Trade-offs: Fan-out on write (Push) provides instant, seamless feed loading for normal users, but fails at scale for high-follower accounts.
• Hybrid Feed Architecture: Combine push models for regular users with pull models for celebrities to prevent write amplification and server crashes.
• Cache Optimization: Store pre-computed user feeds in in-memory caches (Redis) and manage memory bounds efficiently using LRU eviction policies.