Instagram

What the interviewer is asking

"Design Instagram" looks like "Design Twitter" with pictures, and that is the point. The feed, the newest posts from everyone you follow, works the same way, so you can recall that design in a minute. What is new is the photos: one page of the feed carries about 600 times more bytes in images than in text.

The question checks whether you keep big files out of your servers and your database, size storage and bandwidth with rough numbers, and know the tools that move bytes cheaply: object storage, background workers, a CDN and the right image size for each screen. The walkthrough follows the 8 steps of the interview framework: scope, data, API, the busy path, numbers, services, scale and deep dives.

1. Scope: what version 1 must do

• Post a photo with a caption.
• Follow someone.
• See a feed of photos from the people you follow, newest first.
• Like a photo, and see each post's like count.

Name the rest and park it: stories that vanish after 24 hours, reels and other video, direct messages, explore (posts picked for you) and comment threads. Each is a system of its own.

2. Data: posts, follows, likes and the photo bytes

post    id, author_id, caption, time, photo keys (4 sizes), like_count
follow  follower_id → followee_id
like    user_id, post_id, time

The photo's bytes never go in the database. They live in object storage, one object per size under its own key (such as 9001/medium), and the post row keeps only the keys, so it stays about 500 bytes.

The like count copies what the like rows already say: a deliberate copy, because every view of a post shows the count and adding up a million like rows each time would be far too slow. One like row per person and post stops anyone liking twice and lets you recount. Post ids are Snowflake-style, so sorting by id is sorting by time.

3. The API: three calls and a signed upload

POST /posts            {"caption": "Sunset at the pier"}
  → 201 Created        {"id": "9001", "upload_url": "https://…"}
PUT  upload_url        the 2 MB photo, straight to object storage
GET  /feed?cursor=…    → 200 OK  10 posts, newest first, and the next cursor
POST /posts/9001/like  → 200 OK

Posting is the interesting call. Sending the photo through the post service would carry every byte in and straight out again, and a storage key built into the app can be read by anyone who unpacks it. Instead, POST /posts answers with a signed upload URL, which lets the phone write that one key for a few minutes, straight to storage. Following works as in Twitter, and the feed is paged with a cursor, so new posts arriving on top don't shift the pages.

4. The busy path: scrolling the feed

People scroll the feed many times a day and post far less, so loading a page of the feed is the busy path:

1. The app sends GET /feed.
2. The server finds the newest posts of the people the user follows.
3. It answers with 10 posts: captions, like counts and the photos' addresses.
4. The phone downloads the 10 photos.
5. Near the end of the page, the app asks for the next 10 with the cursor.

The answer is about 5 KB of text (10 posts of about 500 bytes); the 10 photos are about 3 MB, 600 times more. The photos decide the design.

5. The numbers

From the interviewer: 500 million daily users, each seeing about 100 photos a day, nearly all as the medium size on a phone; 100 million photos posted a day, each kept in 4 sizes. A day has 86,400 seconds; round it to 100,000.

size        width      bytes
thumbnail   150 px     20 KB
small       480 px     100 KB
medium      1,080 px   300 KB
original    4,000 px   2 MB

• Uploads: 100 million ÷ 100,000 = 1,000 photos a second (about 1,160 exactly), 5,000 at busy hours, bringing in about 2 GB a second.
• Storage: 20 + 100 + 300 + 2,000 KB ≈ 2.4 MB a photo, so about 240 TB a day and 90 PB a year, before object storage's own copies. The three smaller sizes add only about 20%.
• Views: 500 million × 100 = 50 billion photos a day, about 500,000 a second (580,000 exactly).
• Bandwidth out: 500,000 × 300 KB = 150 GB a second (about 174 with 86,400), 750 at busy hours: 150 servers' worth at about 1 GB a second each, and 75 times the bytes coming in.

6. Services: the upload path and the feed service

The upload path. The post service checks who is posting, saves the post row and signs the upload URL. Object storage keeps the original and announces each new object as an event on a queue. Image workers take jobs off the queue, save the thumbnail, small and medium back to storage, and write the sizes' keys into the post row. Nobody waits for them; at busy hours you run more.

The feed service. The feed is Twitter's home timeline again: fan-out on write into a feed cache of post ids per user, with very large accounts' posts pulled at read time. The cache holds 8-byte ids, never photos: pushing a 300 KB photo to, say, 200 followers would copy 60 MB into memory instead of 1.6 KB of ids.

7. Scale: a CDN for the photos

150 GB a second leaving storage in one region, for phones on every continent, is a lot of bytes and slow for faraway users: a round trip between continents takes about 150 ms. Photos suit a CDN perfectly: a photo never changes once made, and many followers see the same one. Say the edges answer 95% of requests: storage sends 7.5 GB a second instead of 150. An in-memory cache can't do this job (240 TB of new photos a day, all in one data center), and more post service servers don't help, since the photos never pass through them.

8. Deep dive: image sizes

The app asks for the smallest size at least as wide as the photo's space on screen:

screen                  space      gets
phone, feed             1,080 px   medium, 300 KB
profile grid, 3 across  360 px     small, 100 KB
older phone, feed       720 px     medium, 300 KB
notifications list      100 px     thumbnail, 20 KB
laptop browser          600 px     medium, 300 KB

A smaller size stretched to fill the space looks soft; a bigger one costs bytes the screen can't show. If every view sent the 2 MB original, the CDN would send 500,000 × 2 MB = 1,000 GB a second instead of 150: the right size saves 850 GB a second, 85% of the bytes. Workers can also make each size in a newer format such as WebP or AVIF, smaller than JPEG for the same picture. Keep the original, so new sizes can be made from it later.

9. Deep dive: the upload pipeline

The phone makes a blurred preview, a tiny blurry copy of the photo in a few dozen bytes, and sends it with the caption. Then:

1. At 0 s the post service saves the post (status uploading) and answers with the signed upload URL.
2. About 2 s later (2 MB at, say, 1 MB a second) the original is in storage. Storage announces it, followers' feeds show the post with its blurred preview, and a job waits on the queue.
3. A worker makes the three sizes, writes their keys into the row and marks the post ready. Feeds swap the blur for the size that fits.

If the worker crashes halfway, the job isn't lost: a queue deletes a job only when a worker says it's done. After a timeout, say 30 seconds, another worker makes all three sizes again, under the same keys with the same bytes, so doing it twice is harmless. The phone doesn't upload again; the original is safe in storage.

10. Deep dive: what the feed sends

For each page the feed service reads the 10 posts' details by id, the hot ones from a cache, and answers:

{"posts": [
  {"id": "9001", "author": "ana", "caption": "Sunset at the pier", "likes": 1204,
   "photos": {"thumbnail": "https://cdn…/9001/t",
              "small": "https://cdn…/9001/s",
              "medium": "https://cdn…/9001/m"}},
  … 9 more posts],
 "cursor": "8873"}

The answer carries addresses, not bytes: it stays about 5 KB, and the phone loads the size that fits from a nearby CDN edge, several at once. The bytes inside would make a 3 MB answer that no edge could reuse, since every feed is different. While the user scrolls, the app prefetches the next few photos. For a private account, the addresses are signed links that expire.

11. Deep dive: likes on a hot post

A celebrity's post gets 1 million likes in an hour: about 280 a second, each adding 1 to the same row. Updates of one row take turns, each locking it until it's saved, so the likes wait in line. Read replicas don't help, since every like is still a write on the leader.

The common fix is batching: each like server adds up likes in memory and writes its total once a second. With three servers, 12 likes in the first second cost 3 writes (1,204 becomes 1,216), and 21 likes over two seconds cost 6. With 10 servers the row gets 10 writes a second however busy the post is. The like rows are still saved, so if a server crashes with up to a second of its count, a recount fixes it. The other common fix is sharded counters: split the count over several rows and add them up when reading.

What breaks first

• Storage cost: about 90 PB a year. Move old originals to a cheaper, colder storage class.
• The posts database: 100 million rows a day at about 500 bytes is about 50 GB a day. Shard it by post id.
• A celebrity's post: read in millions of feeds. Cache its row, with copies on several cache servers.
• The image workers at busy hours: 5,000 photos a second. Add workers; the queue absorbs the bursts.

Summary: the order to follow

1. Scope: post a photo, follow, see the feed, like; park the rest.
2. Data: posts (with the sizes' keys and a like count), follows, likes; bytes in object storage.
3. API: POST /posts with a signed upload URL, GET /feed?cursor=…, POST /posts/{id}/like.
4. Busy path: scrolling the feed, almost all of it photos.
5. Numbers: about 240 TB stored a day; about 150 GB a second out.
6. Services: uploads straight to storage, image workers off a queue, a feed service.
7. Scale: a CDN sends the photos from near the viewers.
8. Deep dives: the smallest size that covers the screen; a blurred preview and jobs that run again; feeds that carry addresses; likes added up in memory.

Every design with photos, video or documents reuses this pipeline: object storage, signed uploads, background workers and a CDN.