Design Instagram

Instagram is a photo and video sharing social networking service that allows users to share photos and videos, follow other users, and interact through likes and comments. With over 2 billion monthly active users, Instagram faces unique engineering challenges around content delivery, feed generation, real-time updates, and massive scale.

Designing Instagram requires addressing several complex problems: efficient feed generation for billions of users, fast content delivery globally, handling high read/write ratios, real-time story features, and maintaining system performance during viral events.

Step 1: Understand the Problem and Establish Design Scope

Before diving into the design, let’s define the functional and non-functional requirements clearly. For user-facing applications like this, functional requirements are the “Users should be able to…” statements, whereas non-functional requirements define system qualities via “The system should…” statements.

Functional Requirements

Core Requirements (Priority 1-3):

Users should be able to upload photos and videos (up to 1 minute for regular posts, 15 seconds for stories).
Users should be able to follow other users and see their posts in a personalized feed.
Users should be able to like, comment on, and share posts.
Users should be able to view and post stories that disappear after 24 hours.

Below the Line (Out of Scope):

Users should be able to send direct messages to other users.
Users should be able to go live and broadcast video in real-time.
Users should be able to use augmented reality (AR) filters on photos and videos.
Users should be able to shop through Instagram Shopping features.
Search and explore functionality with personalized recommendations.

Non-Functional Requirements

Core Requirements:

The system should prioritize low latency for feed loading (< 500ms to fetch initial feed).
The system should be highly available (99.99% uptime).
The system should be eventually consistent for social features (likes, follower counts can be slightly stale).
The system should scale to handle billions of users and hundreds of millions of daily active users.

Below the Line (Out of Scope):

The system should ensure data privacy and compliance with regulations (GDPR, CCPA).
The system should have comprehensive monitoring, alerting, and observability.
The system should support A/B testing infrastructure for algorithm experimentation.

Clarification Questions & Assumptions:

Platform: Mobile apps (iOS, Android) and web.
Scale: 2 billion monthly active users, 500 million daily active users.
Upload Volume: 100 million photos/videos uploaded per day.
Read:Write Ratio: Heavy read (100:1 ratio) - users browse much more than they post.
Feed Refresh Rate: Users refresh feed multiple times per day.
Geographic Distribution: Global audience, need CDN for content delivery.

Step 2: Propose High-Level Design and Get Buy-in

Planning the Approach

Before moving on to designing the system, it’s important to plan your strategy. For user-facing product-style questions, the plan should be straightforward: build your design up sequentially, going one by one through your functional requirements. This will help you stay focused and ensure you don’t get lost in the weeds.

Defining the Core Entities

To satisfy our key functional requirements, we’ll need the following entities:

User: Represents an Instagram user with profile information including username, bio, profile picture, and follower/following counts. Users can be regular users, verified users, or business accounts. Contains authentication credentials, preferences, and privacy settings.

Post: Represents a photo or video shared by a user. Contains the media URL pointing to object storage, caption text, optional location tag with coordinates, timestamp of creation, aggregated like count, comment count, and metadata used for feed ranking and recommendations.

Follow: Represents a follower relationship between two users. This is a directed edge in the social graph where User A follows User B. The relationship is one-way unless both users follow each other.

Like: Represents a like on a post by a user. Tracks which user liked which post and when. This is a many-to-many relationship between users and posts with timestamp information.

Comment: Represents a comment on a post, including the comment text, author information, timestamp, and potentially nested replies. Supports threaded conversations with parent-child relationships.

Story: A temporary post that expires after 24 hours. Contains media URL, timestamp of creation, view count, expiration time, and viewer list for analytics.

Feed: A personalized timeline of posts for a user, generated from the accounts they follow. May include recommended content based on user interests and engagement patterns.

API Design

Upload Post Endpoint: Allows users to upload a photo or video with associated metadata.

POST /posts -> Post

The request includes the media file, caption text, optional location coordinates, and tags. The response includes a presigned URL for uploading media to object storage and creates the post metadata in the database.

Get Feed Endpoint: Retrieves a personalized feed for the user with pagination support.

GET /feed?cursor={cursor}&limit={limit} -> FeedResponse

Uses cursor-based pagination for efficient scrolling through large feeds. Returns an array of posts, the next cursor for pagination, and a boolean indicating if more posts are available.

Follow User Endpoint: Allows a user to follow another user.

POST /users/{userId}/follow -> Success/Error

Creates a follower relationship in the social graph and may trigger feed regeneration for the follower. Updates follower counts for both users.

Like Post Endpoint: Allows a user to like a post.

POST /posts/{postId}/like -> Success/Error

Increments like count atomically and records the like in the database with timestamp. Implements idempotency to prevent duplicate likes.

Post Comment Endpoint: Allows a user to comment on a post.

POST /posts/{postId}/comments -> Comment

The request includes the comment text and optional parent comment ID for nested replies. Returns the created comment with metadata.

Upload Story Endpoint: Allows users to post a story that expires automatically.

POST /stories -> Story

Similar to post upload but with automatic 24-hour expiration. Returns story metadata including expiration timestamp.

Get Stories Endpoint: Retrieves unexpired stories from followed users.

GET /stories -> StoryResponse

Returns stories grouped by user, sorted by timestamp, with view status information.

High-Level Architecture

Let’s build up the system sequentially, addressing each functional requirement:

1. Users should be able to upload photos and videos

Core components for media upload:

Mobile/Web Client: User interface for capturing and uploading media. Handles image compression, format conversion, and upload progress tracking.
API Gateway: Entry point for all client requests, handles authentication using JWT tokens, rate limiting to prevent abuse, and request routing to appropriate backend services.
Upload Service: Orchestrates the upload process, generates presigned URLs for direct upload to object storage, validates file types and sizes.
Object Storage (S3): Stores original high-resolution media files. Provides durability (99.999999999%) and scalability to handle billions of objects.
CDN (CloudFront/Akamai): Caches and delivers media globally with low latency. Edge locations in hundreds of cities worldwide reduce latency for users.
Image Processing Service: Asynchronously processes uploaded media to create multiple sizes and formats including thumbnails, medium quality, and high quality versions for different devices and network conditions.
Media Metadata Database: Stores metadata about media files including URLs for different versions, dimensions, format, processing status, and content hash for deduplication.

Upload Flow:

User selects a photo or video in the client app and adds caption and tags.
Client requests a presigned upload URL from the Upload Service via API Gateway.
Upload Service generates a presigned S3 URL valid for 15 minutes and returns it to the client.
Client uploads the media file directly to S3 using the presigned URL, bypassing application servers for efficiency and reducing bandwidth costs.
S3 triggers an event notification via SNS or SQS to the Image Processing Service when upload completes.
Image Processing Service fetches the original media, creates multiple versions with resizing, compression, and format conversion optimized for different viewing contexts.
Processed media versions are uploaded back to S3 and automatically cached in CDN for fast global delivery.
Media Metadata Database is updated with all media URLs, processing status, and metadata.

2. Users should be able to follow other users and see their posts in a personalized feed

Additional components needed:

User Service: Manages user profiles, authentication, and user-related operations including profile updates, password management, and account settings.
Graph Service: Manages the social graph representing follow relationships. Stores who follows whom with efficient data structures for graph traversal.
Post Service: Manages post creation, retrieval, and metadata. Handles post lifecycle from creation to deletion.
Feed Service: Generates personalized feeds for users based on their social graph, engagement history, and ranking algorithms.
Feed Database/Cache: Stores pre-computed feeds or feed data for fast retrieval with minimal latency.
Newsfeed Cache (Redis): In-memory cache for recently generated feeds to minimize database hits and reduce latency.

Feed Generation Flow:

There are two fundamental approaches to feed generation, each with distinct trade-offs:

Approach A: Fan-out-on-write (Push Model) When User A creates a post, the Post Service stores it in the Posts Database. The system asynchronously fetches all of User A’s followers from the Graph Service. For each follower, the system inserts the new post into their pre-computed feed cache. When a user requests their feed, the system simply reads from their pre-computed feed cache.

Pros: Fast feed retrieval since feeds are pre-computed. Minimal latency for users checking their feed. Cons: Expensive for users with millions of followers (the celebrity problem). High write amplification where a single post generates millions of writes.

Approach B: Fan-out-on-read (Pull Model) When User A creates a post, it’s simply stored in the Posts Database. When a user requests their feed, the Feed Service fetches all accounts the user follows from the Graph Service, queries the Posts Database for recent posts from those accounts, and ranks and assembles the feed in real-time.

Pros: No write amplification. Efficient for celebrity accounts with millions of followers. Cons: Slower feed generation since computed on-demand. High read load on the database when users request feeds.

Hybrid Approach (Instagram’s Solution): The system uses fan-out-on-write for normal users with fewer than one million followers. For celebrities and verified accounts, it uses fan-out-on-read to avoid write amplification. The system pre-computes partial feeds and merges content on-demand for optimal performance. Frequently accessed feeds are cached in Redis with 5-10 minute TTL to balance freshness and performance.

Additional components:

Engagement Service: Handles likes, comments, shares, and other engagement metrics. Processes high volumes of engagement events with low latency.
Engagement Database: Stores likes and comments with appropriate indexing for efficient queries. Partitioned to handle billions of engagement events.
Counter Service: Manages aggregated counters including like count and comment count using Redis for fast atomic updates with eventual consistency to the main database.

Like Flow:

User taps the like button on a post, sending a POST request to the like endpoint with the post ID.
API Gateway authenticates the request and forwards to Engagement Service.
Engagement Service checks if user already liked the post to prevent duplicate likes using a composite index on user ID and post ID.
If not already liked, inserts a new like record into Engagement Database with timestamp.
Increments the like counter in Redis asynchronously for fast response.
Updates the Posts Database with the new like count using eventual consistency.
Client receives success response and updates UI optimistically before server confirmation.
Post author may receive a push notification about the new like via the Notification Service.

Comment Flow:

User submits a comment, sending POST request with comment text and optional parent comment ID for replies.
Engagement Service validates the comment length and checks for spam or profanity using content moderation filters.
Comment is stored in Engagement Database with nested reply support using parent comment ID for threading.
Comment count is incremented in both Redis and Posts Database.
Post author receives a push notification about the new comment with preview text.
Comment is immediately visible to the author and gradually propagates to other viewers.

4. Users should be able to view and post stories that disappear after 24 hours

Additional components:

Story Service: Manages story creation, retrieval, and expiration. Handles the unique lifecycle of temporary content.
Story Database: Stores stories with TTL (Time-To-Live) indexing for automatic expiration. Optimized for time-based queries.
Story Cache (Redis): Caches active stories for the last 24 hours using sorted sets for efficient range queries by timestamp.

Story Flow:

User creates a story, uploading media via presigned URL similar to regular posts.
Story Service creates a story record with expiration timestamp calculated as current time plus 24 hours.
Story is stored in Story Database with a TTL index for automatic cleanup.
Active stories are cached in Redis sorted sets sorted by timestamp for fast retrieval.
When users view their story feed, Story Service queries Redis for unexpired stories from followed accounts.
A background job periodically scans Story Database and deletes expired stories or uses database TTL features for automatic cleanup.
Story views are tracked in a separate analytics database for story insights and viewer lists.
Users can see who viewed their stories with timestamp information.

Step 3: Design Deep Dive

Now let’s dive deeper into the critical technical challenges. These are the areas that separate good designs from great ones.

Deep Dive 1: How do we optimize feed generation for billions of users?

The feed is the core feature of Instagram, and generating it efficiently at scale is challenging.

Problem: Generating a personalized feed for 500 million daily active users in under 500ms while maintaining freshness and relevance.

Solution: Hybrid Feed Generation with Multi-Level Caching

The solution involves multiple caching layers working together:

Layer 1: Pre-Computed Feed Cache (Hot Users) For active users who check their feed multiple times per day, the system maintains a pre-computed feed in Redis. Use fan-out-on-write for normal users with fewer than 100,000 followers. The cache stores post IDs rather than full post data to save memory and reduce cache size. TTL is set to 10 minutes to balance freshness with cache efficiency.

Layer 2: On-Demand Feed Assembly For cold users who haven’t checked feed recently or celebrity followers, the system assembles feed on-demand. Fetch following list from Graph Service, which is cached in Redis for fast access. Query Posts Database for recent posts from followed users within the last 7 days. Rank posts using a feed ranking algorithm that considers chronological order and engagement signals.

Layer 3: Feed Ranking Algorithm The ranking algorithm combines multiple signals to determine post order. Chronological score gives newer posts higher scores to maintain freshness. Engagement score ranks posts with more likes and comments higher. Relationship score prioritizes posts from users you interact with frequently. Content type score prefers media types user engages with such as photos versus videos. Diversity ensures feed isn’t dominated by a single user or content type.

Machine Learning Integration: The system uses a lightweight ML model to predict user engagement probability for each post. Features include user history, post metadata, author relationship strength, content type, and time of day. The model runs inference at feed generation time with latency under 50ms per request to maintain overall feed load time under 500ms.

Feed Pagination: Use cursor-based pagination encoding last post ID and timestamp in an opaque cursor string. Client fetches feed in batches of 20-30 posts for efficient loading. Pre-fetch next page in background for seamless scrolling experience.

Deep Dive 2: How do we handle media storage and delivery at global scale?

Problem: Delivering billions of images and videos globally with low latency and managing storage costs efficiently.

Solution: Multi-Tier Storage and CDN Strategy

Storage Tier 1: Hot Storage (S3 Standard) Stores recently uploaded media from the last 30 days. Provides high durability and availability with fast access times. Integrated with CDN for immediate global delivery.

Storage Tier 2: Warm Storage (S3 Infrequent Access) Stores media from 30-365 days ago. Lower cost per GB but slightly higher retrieval latency which is acceptable for older content. Moved automatically using S3 lifecycle policies.

Storage Tier 3: Cold Storage (S3 Glacier) Stores media older than 1 year that is rarely accessed. Cheapest storage option with significantly lower costs. Higher retrieval latency of minutes to hours is acceptable for archived content.

CDN Strategy: Use multi-CDN approach with CloudFront, Akamai, and Fastly for redundancy and performance. Edge locations in 200+ cities worldwide bring content close to users. Cache hit ratio exceeds 95% for popular content reducing origin server load. Cache invalidation on content updates is rare since Instagram posts are immutable after creation.

Image Optimization: Generate multiple formats including JPEG for photos, WebP for modern browsers with better compression, and HEVC for videos. Use progressive JPEG for faster perceived loading where users see low-resolution preview quickly. Implement lazy loading for images below the fold to reduce initial page load time. Serve responsive images with appropriate size based on device screen resolution and network conditions.

Deep Dive 3: How do we scale the database to handle billions of posts and users?

Problem: Single database cannot handle the read/write load and storage requirements at Instagram’s scale.

Solution: Database Sharding and Read Replicas

Sharding Strategy: The system uses different sharding strategies for different data types. User sharding distributes users across shards by user ID using consistent hashing to minimize resharding when adding new shards. The shard key uses modulo operation on user ID. Post sharding distributes posts by post ID since posts are mostly written once and read many times. Consider time-based sharding where newer posts are in separate shards for better cache locality. Engagement sharding distributes likes and comments by post ID to co-locate engagement data with post data for efficient queries.

Read Replicas: Each shard has 3-5 read replicas for scaling reads horizontally. Use read replicas for all GET requests to distribute load. Primary shard handles writes only to maintain consistency. Asynchronous replication provides eventual consistency which is acceptable for social features. Replica lag monitoring ensures replicas don’t fall too far behind.

Database Technology Choices: User and profile data uses PostgreSQL for strong consistency and ACID guarantees needed for account operations. Posts and feed data uses Cassandra for high write throughput and tunable consistency levels. Social graph uses specialized Graph Database like Neo4j or custom adjacency list implementation in Cassandra for efficient graph traversal. Engagement counters use Redis for in-memory fast atomic increments with persistence to disk.

Deep Dive 4: How do we handle the celebrity problem in feed generation?

Problem: When a celebrity with 100 million followers posts, fan-out-on-write becomes prohibitively expensive, generating 100 million cache writes.

Solution: Hybrid Fan-out with Lazy Loading

Detection: Classify users into tiers based on follower count. Tier 1 includes users with fewer than 10,000 followers (regular users). Tier 2 includes users with 10,000 to 1 million followers (influencers). Tier 3 includes users with more than 1 million followers (celebrities and verified accounts).

Tier-Based Strategy: For Tier 1 regular users, use full fan-out-on-write where their posts are pushed to all followers’ feed caches. For Tier 2 influencers, use partial fan-out pushing only to active followers who logged in within last 24 hours. For Tier 3 celebrities, use no fan-out and fetch posts on-demand when followers request their feed.

Feed Assembly for Celebrity Followers: First fetch pre-computed feed from cache containing posts from regular users they follow. Identify which celebrities the user follows from the social graph. Query Posts Database for recent posts from those celebrities within the last 7 days. Merge celebrity posts with pre-computed feed using ranking algorithm considering recency and engagement. Cache the merged feed for 5 minutes to serve subsequent requests efficiently.

Optimization: Celebrities’ recent posts are cached aggressively in Redis since millions of followers will request them. Use cache warming to pre-cache celebrity posts before they’re requested based on prediction models. Monitor cache hit rates and adjust caching strategy accordingly.

Deep Dive 5: How do we implement real-time notifications for likes, comments, and follows?

Problem: Users expect instant notifications when someone likes their post, comments, or follows them.

Solution: Event-Driven Architecture with Push Notifications

Components: Event Bus using Kafka streams all engagement events including likes, comments, and follows. Notification Service consumes events and decides which to send as notifications based on user preferences and rules. Push Notification Gateway sends push notifications via APNs for iOS and FCM for Android. WebSocket Service maintains persistent connections for real-time web updates.

Flow: When User A likes User B’s post, Engagement Service writes the like to the database and publishes a POST_LIKED event to Kafka. Notification Service consumes the event and checks several conditions. Is User B’s notification preference enabled for likes? Is this a significant notification such as the 100th like on the post? Rate limiting ensures we don’t overwhelm users with too many notifications. If conditions are met, Notification Service creates a notification record and sends it to Push Notification Gateway. Push Notification Gateway sends to APNs or FCM based on device type. For web users, WebSocket Service pushes the notification in real-time without polling.

Deduplication: Use Redis to track recently sent notifications and prevent duplicates within a time window. Batch similar notifications such as “John and 10 others liked your post” to reduce notification fatigue. Update batched notifications in real-time as more events arrive.

Deep Dive 6: How do we ensure stories expire after exactly 24 hours?

Problem: Need to automatically delete millions of stories after 24 hours without impacting system performance.

Solution: TTL-Based Expiration with Background Jobs

Approach 1: Database TTL (Cassandra) Use Cassandra’s native TTL feature to set expiration time on story rows. When TTL expires, Cassandra automatically tombstones and deletes the data. Pros include automatic cleanup with no custom code needed. Cons include tombstone accumulation that can impact read performance if not managed properly.

Approach 2: Background Deletion Job Store stories with an expires_at timestamp column. Run a background job every hour that queries for expired stories and deletes them in batches. Use indexed query on expires_at column for efficient lookup. Batch delete in chunks of 1000 to avoid overwhelming the database with large delete operations.

Approach 3: Hybrid (Instagram’s Solution) Use Redis sorted sets for active stories from the last 24 hours. The score is the expiration timestamp allowing efficient range queries. When fetching stories, filter by score to return only unexpired stories. Background job runs every 10 minutes executing sorted set range removal by score. Persist stories in Cassandra with TTL as backup and for analytics. On read, check Redis first for fast access and fall back to Cassandra if needed.

Viewing Stories: When user opens story feed, fetch all unexpired stories from followed users using sorted set operations. Use Redis sorted set intersection to find stories from users the viewer follows. Mark stories as viewed in a separate database for analytics and viewer lists. Update view count asynchronously to avoid impacting story load time.

Step 4: Wrap Up

We’ve designed a comprehensive system for Instagram covering photo/video sharing, feed generation, engagement features, and stories. If there is extra time at the end of the interview, here are additional points to discuss:

Additional Features:

Direct Messaging: Use WebSocket for real-time messaging, store messages in Cassandra sharded by conversation ID, implement end-to-end encryption for privacy.
Search & Explore: Use Elasticsearch for hashtag search and user search, ML-powered content recommendations based on user interests and engagement patterns.
Live Video: Use WebRTC for peer-to-peer streaming, HLS for scalability with many viewers, separate live video service with real-time chat.
Shopping: Integrate with payment providers, maintain product catalog database, use recommendation engine to suggest products based on user preferences.

Scalability Considerations:

Horizontal Scaling: All services are stateless and can scale horizontally behind load balancers. Use container orchestration with Kubernetes for automated scaling.
Database Partitioning: Shard by user ID and post ID for even distribution of data and load across database nodes.
Caching Layers: Implement multi-level caching including client-side cache, CDN for media, Redis for application data, and database query cache.
Async Processing: Use message queues like Kafka or SQS for all non-critical operations including analytics, notifications, and media processing.

Reliability & Fault Tolerance:

Multi-Region Deployment: Active-active deployment in multiple AWS regions for disaster recovery and reduced latency.
Circuit Breakers: Prevent cascading failures when downstream services fail by failing fast and providing fallbacks.
Rate Limiting: Protect services from abuse and traffic spikes using token bucket or leaky bucket algorithms.
Graceful Degradation: Show stale feed or reduced functionality rather than complete failure to maintain user experience.

Monitoring & Observability:

Metrics: Track feed load time, upload success rate, like/comment latency, error rates, and database query performance.
Distributed Tracing: Use Jaeger or Zipkin to trace requests across microservices and identify bottlenecks.
Alerting: On-call rotations with PagerDuty alerts for critical issues affecting user experience.
Dashboards: Real-time dashboards showing system health, user engagement metrics, and business KPIs.

Security & Privacy:

Authentication: JWT tokens with short expiration, refresh token rotation to prevent token theft.
Authorization: Role-based access control (RBAC) for admin features and content moderation tools.
Content Moderation: ML-based detection of inappropriate content, human review queue for flagged content.
Data Privacy: GDPR compliance, user data export functionality, right to deletion with complete data removal.

Performance Optimizations:

Feed Pre-fetching: Pre-fetch next page of feed in background while user scrolls through current page.
Lazy Loading: Load images as they enter viewport to reduce initial page load time and bandwidth usage.
Client-Side Caching: Cache feed data locally on device to reduce server load and enable offline viewing.
GraphQL: Use GraphQL to allow clients to request exactly the data they need, reducing over-fetching.

Machine Learning Applications:

Feed Ranking: Personalized feed ranking based on user preferences, engagement history, and content features.
Content Recommendations: Suggest accounts to follow based on social graph analysis and interest similarity.
Spam Detection: Identify and filter spam comments, fake accounts, and bot activity using behavior patterns.
Image Recognition: Auto-tagging of photos, content moderation, and accessibility features like alt text generation.

Database Optimization:

Indexing Strategy: Create appropriate indexes on frequently queried columns while balancing write performance.
Query Optimization: Use EXPLAIN plans to optimize slow queries, avoid N+1 query problems.
Connection Pooling: Manage database connections efficiently to handle high concurrency.
Data Archival: Move old inactive data to cheaper cold storage to reduce active database size.

Cost Optimization:

Storage Tiering: Move infrequently accessed media to cheaper storage tiers automatically.
CDN Optimization: Optimize cache hit rates to reduce origin server load and bandwidth costs.
Reserved Capacity: Use reserved instances for predictable baseline load, spot instances for batch processing.
Compression: Compress data in transit and at rest to reduce bandwidth and storage costs.

Designing Instagram is a fascinating challenge that combines social networking, content delivery, real-time systems, and machine learning. The key is to start with core functionality, understand the scaling challenges early, and iteratively optimize based on actual usage patterns and bottlenecks.

Summary

This comprehensive guide covered the design of a photo and video sharing platform like Instagram, including:

Core Functionality: Media upload and storage, feed generation, engagement features (likes and comments), stories with 24-hour expiration.
Key Challenges: Feed generation at scale, celebrity problem, global content delivery, real-time features, data consistency.
Solutions: Hybrid fan-out strategy, multi-tier storage with CDN, database sharding, Redis caching, event-driven architecture, TTL-based expiration.
Scalability: Horizontal scaling, multi-region deployment, async processing, ML-powered ranking.

The design demonstrates how to build a highly scalable social media platform that handles billions of users, maintains low latency, and provides a delightful user experience globally.

Design Instagram