Design Instagram - System Design Interview
With over 2 billion monthly active users, Instagram is the 3rd most popular social network after Facebook and YouTube.
It enables users to upload photos and videos, interact with content, while handling hundreds of millions of daily visitors, managing petabytes of data, billions of views, all while maintaining low latency and high availability.
Given its scale and complexity, designing Instagram is a popular system design interview question.
While Instagram supports a wide range of features including direct messaging, Reels, and Stories—this article will primarily focus on the core functionality of photo and video sharing.
We’ll walk through every step of the design—from requirements and high-level architecture to database and API design—before diving deep into core use cases.
1. Requirement Clarification
Before diving into the design, lets outline the functional and non-functional requirements.
Functional Requirements
Users can upload photos and videos.
Users can add captions to their posts.
Users can follow/unfollow other users.
Users can like, share, and comment on posts.
Support for multiple images/videos in a single post (carousel).
Users can view a personalized feed consisting of posts from accounts they follow.
Users can search by username and hashtag.
Out of Scope
Direct messaging.
Short-form video content (Reels).
Push Notifications for likes, comments, and follows.
Non Functional Requirements
Low Latency: The feed should load fast (~100ms).
High Availability: The system should be available 24/7 with minimal downtime.
Eventual Consistency: A slight delay in users seeing the latest posts from accounts they follow is acceptable.
High Scalability: Handle millions of concurrent users and billions of posts.
High Durability: The uploaded photos/videos shouldn’t be lost.
2. Capacity Estimation
User Base
Total Monthly Active Users (MAUs): 2 billion
Daily Active Users (DAUs): → 500 million users/day
Estimating Read & Write Requests
Post Uploads (Writes)
100M media uploads/day
Each upload generates metadata writes (DB + cache)
Total write requests: 100M uploads + 100M metadata writes = 200M writes/day
Feed Reads
Assume an average user scrolls through 100 posts per session
500 million DAUs × 100 posts viewed = 50B feed requests/day
Assuming 80% of feed reads are served from cache, backend reads = 10B DB reads/day
Estimating Storage Requirements
Assumptions
20% of DAUs (100M) upload media every day
80% of uploads are photos, 20% are videos
Average photo size: 1MB
Average video size: 10 MB
Daily Storage Calculation
Photos: (100M × 80%) × 1 MB = 80 TB/day
Videos: (100M × 20%) × 10 MB = 200 TB/day
Total storage per day: 280 TB/day
Database Storage
Metadata per post: ~500 bytes (caption, timestamp, author, engagement counts)
Total posts in a year: 100M × 365 = 36B posts
Metadata storage per year: 90 TB/year
Caching Requirements
Hot cache size: Store recent & popular 1 billion posts
Assume each cached post takes 2 KB (post data + engagement counts)
Cache size = 2 TB for active posts (Redis/Memcached)