Loading...
High availability — if Instagram goes down users can't see photos or their feed
Low latency — feed loads under 100ms, media served from nearest CDN edge node
Scalability — hundreds of millions of users uploading and viewing photos daily
Eventual consistency — okay if a new post takes a few seconds to appear in followers' feeds
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
POST /upload
input: { user_id, media_file, caption }
output: { post_id, cdn_url }
DELETE /posts/:post_id
input: { user_id }
output: { confirmation }
POST /posts/:post_id/like
input: { user_id }
output: { like_count }
DELETE /posts/:post_id/like
input: { user_id }
output: { like_count }
POST /users/:user_id/follow
input: { follower_id }
output: { confirmation }
DELETE /users/:user_id/follow
input: { follower_id }
output: { confirmation }
GET /feed
input: { user_id, page }
output: { list of posts with cdn_urls and captions }
GET /notifications
input: { user_id }
output: { list of unread notifications }
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
"The client hits the API gateway which handles auth and rate limiting. The load balancer routes to five services — upload service, like service, follow service, feed service, and notification service. When a user uploads a photo or video, the upload server receives the file, stores it in S3, saves the metadata and CDN URL to the database, and returns the CDN URL to the client. All media reads go through the CDN so users always hit the nearest edge node instead of hitting S3 directly. Likes and follows are write-heavy and non-critical so they go through Kafka and are processed asynchronously by a worker server. The feed service is read-heavy and checks Redis cache before hitting the database. A background scheduler runs periodically to precompute and refresh feed rankings. All writes go to the primary database which replicates to a secondary for redundancy."
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
"The upload service is the entry point for all media. It receives the file from the client, uploads it to S3, and stores the post metadata including the S3 URL in the database. The CDN automatically caches the file from S3 on first request and serves all subsequent reads from the nearest edge node. This means a photo uploaded once in Virginia can be served instantly to users in Tokyo without hitting the origin server.
The like service handles extremely high write volume — popular posts can receive thousands of likes per second. Writing each like synchronously would overwhelm the database so likes are dropped into Kafka immediately and the user gets an instant response. The worker server consumes from Kafka, batches the events, and writes them to the database in bulk.
The feed service is the most read-heavy component. Each user's feed is precomputed and stored in Redis cache keyed by user ID. When a new post is uploaded the worker pushes it into relevant followers' feed caches. The scheduler runs every few minutes to refresh rankings based on engagement. Feed reads are almost always cache hits and never touch the database directly."