System Design Interview: Design Instagram 📸
AS
Anthony SandeshInstagram is one of the world’s largest social platforms, centered around sharing photos and videos. In this post, we’ll break down how to design Instagram step by step — just like you’d explain in a system design interview.
We’ll cover requirements, architecture, scaling challenges, data modeling, caching, APIs, and more — with diagrams to keep things visual.
✅ Functional Requirements
- Upload and share photos/videos (with captions, tags).
- Profiles & follow system (social graph).
- News feed (personalized timeline of posts).
- Likes & comments on posts.
- Search & discovery (users, hashtags, posts).
- Direct messaging (real-time chat).
- Notifications (likes, follows, comments).
⚙️ Non-Functional Requirements
- Scalability → handle hundreds of millions of users.
- Low latency → feed generation < 200ms.
- High availability → 24/7 uptime.
- Durability → never lose photos.
- Eventual consistency → acceptable for feeds/likes.
- Security & privacy → protect user data.
🏛️ High-Level Architecture
Key ideas:
- Load balancer spreads requests across many stateless app servers.
- Microservices handle user, media, feed, notifications, messaging.
- CDN + Object Store for massive photo/video storage.
- Caches (Redis/Memcached) to speed up hot data.
- SQL + NoSQL mix: relational DB for users/posts, NoSQL for feeds.
🖼 Media Storage & Delivery
- Use distributed object storage (e.g., S3, GCS) for photos/videos.
- Store multiple sizes (thumbnail, medium, full) at upload.
- Serve via CDN for low-latency global delivery.
- Metadata (caption, tags, URL) stored in DB, not the binary file.
📰 Feed Generation
Options
- Fan-out on write (Push): When Alice posts → copy into all followers’ feeds. (Fast reads, heavy writes).
- Fan-out on read (Pull): Bob opens app → fetch posts from people he follows. (Cheap writes, slow reads).
- Hybrid: Push for most users, pull for celebrities with millions of followers.
Implementation
- Feed entries stored in a Feed DB (NoSQL like Cassandra/DynamoDB).
- Async workers process fan-out events via queues.
- Use Redis caching for hot feeds.
🗃 Data Modeling
Users Table
Posts Table
Follows Table
Likes Table
FeedEntries (NoSQL Example)
⚡ Caching Strategies
- CDN → cache media globally.
- Redis/Memcached → cache feeds, user profiles, like counts.
- TTL-based expiration for feeds.
- Write-through cache for likes/comments counters.
🔌 API Design Examples
- All endpoints paginated.
- Rate limiting via API Gateway.
- Stateless → each request carries auth token.
🔔 Notifications & 💬 Messaging
- Use event-driven architecture for likes/follows/comments.
- Notification service stores alerts + pushes to APNs/FCM.
- Messaging via persistent connections (WebSockets/MQTT) for real-time chat.
⚖️ Load Balancing & Rate Limiting
- Load balancers at all layers → no single point of failure.
- Geo load balancing → route users to nearest data center.
- Rate limiting at API Gateway → e.g., 100 feed requests/min per user.
- Implemented with Redis counters or token bucket algorithm.
🎯 Conclusion
Designing Instagram is a masterclass in system design:
- Object storage + CDN for media.
- Push-based feed with hybrid fallback for scale.
- SQL + NoSQL + Cache for different workloads.
- Event-driven notifications and real-time messaging.
- Load balancing & rate limiting to keep things reliable.
With this architecture, Instagram can handle billions of daily requests while still delivering photos in milliseconds 🚀.
