Design Instagram

Clarify the ask

The interview prompt is short. Design Instagram.

The service centres on photos. Users post photos, follow accounts and read what followed accounts post.

Each missing detail is settled out loud. Scale matters from the start, since photos make storage a first-order concern.

Functional requirements

Uploading a photo is the main write. A user picks a photo, adds a caption and publishes it.

Following links one user to an account. The link decides whose photos reach the user's feed.

The feed is the main read. It shows recent photos from followed accounts.

Stories are short-lived posts. A story stays visible for a short set time and then disappears.

Likes and comments support the main flows. Direct messages stay out of scope.

Non-functional requirements

A photo must not be lost after an upload reports success. Upload safety matters more than upload speed.

The feed must open fast. Reading photos is the hot path of the service.

A feed can lag a little. A photo that reaches a follower's feed a moment late is acceptable.

Photo quality must survive the path. The service stores the original photo, not only a reduced copy.

Estimate the scale

The counts are the stated assumptions of this problem, starting with 100,000,000 photos uploaded a day.

100,000,000 photos ÷ 86,400 seconds = 1,157 uploads per second.

An average photo takes 200 KB.

100,000,000 photos × 200 KB = 20 TB of new photos a day.

20 TB a day × 365 days = 7,300 TB of new photos a year.

Story views reach 500,000,000 a day. Stories add a heavy read flow on top of uploads.

Where the depth sits

Photos are heavy. Storage and delivery dominate this design in a way text posts never did.

The feed reuses the fan-out ideas from the earlier courses. Photos change what a feed entry can hold.

A feed entry can hold a reference to a photo, never the photo bytes. That single choice shapes the feed design.

Deep dive the upload

The upload path runs from the client's request to a photo ready to serve.

The client first asks an app server for an upload address. The app server creates a photo record in a waiting state.

The client then uploads the photo bytes straight to blob storage. Blob storage is the taught store for large binary objects.

Direct upload keeps heavy bytes off the app servers. They stay free for small control requests.

Confirming the upload

Blob storage reports the stored size when the upload ends. The client also sends a checksum, a short fingerprint of the photo bytes.

The service compares the size and the checksum with the stored object. A match marks the photo record ready.

A failed match keeps the photo hidden. The client retries the upload, and no broken photo ever appears.

Metadata is written only for a confirmed upload. The feed can trust every ready photo record it meets.

Processing into sizes

A ready photo is processed by background jobs. Each job run makes the stored sizes of the photo.

The sizes serve different screens. A small size serves the feed grid, and the full size serves an opened photo.

The original photo is kept unchanged. New sizes can always be made again from the original.

A failed job retries from the queue. A job that keeps failing lands in the dead-letter queue for inspection.

Storing the originals

Originals and sizes live in blob storage. Photo metadata lives in a database sharded by user id.

The metadata record holds the photo id, the owner id, the caption and the storage addresses of each size.

Replication keeps more than one copy of every photo. Three copies are the design's stated choice.

20 TB of new photos a day × 3 copies = 60 TB of new stored data a day.

Copies sit in more than one data center. Losing one data center loses no confirmed photo.

Serving photos back

A CDN serves photo bytes to viewers. Popular sizes are cached near viewers, so most reads never reach blob storage.

The cache names a photo by its photo id and size. One cached copy serves every viewer of that size.

Originals are served rarely. Almost all reading traffic goes to the smaller stored sizes.

Where upload breaks

A retry can upload the same photo twice. The client sends one upload id with the photo, and repeats reuse that id.

The service stores one photo per upload id. A repeated upload returns the first photo record instead of a copy.

A processing backlog delays new sizes, never the upload itself. The original is already safe while sizes catch up.

Deep dive the feed

The feed is where fan-out meets heavy photos and ranking.

The feed reuses the hybrid fan-out from the earlier courses. Normal accounts push, and very large accounts pull.

Photos change the payload, not the shape. The fan-out machinery moves references, never bytes.

Feed entries hold photo ids in order. Blob storage holds the photo bytes.

The CDN holds popular photo sizes. The feed service holds ranked photo ids.

Fan-out with photo references

A feed entry holds the photo id, the owner id and the posting time. It holds no photo bytes.

Fan-out on write copies that small entry into follower feeds at post time. Copying stays cheap even for photos.

Reading a feed page fetches the entries first. The client then loads each photo size from the CDN by photo id.

A slow photo load never blocks the feed itself. The page structure arrives even while one photo is still loading.

The large-account case in numbers

Consider a worked example. One account has 10,000,000 followers in this example.

10,000,000 followers × 1 photo post = 10,000,000 feed writes for one post.

At 100,000 writes per second, those writes take 100 seconds.

That delay lands on every post from the account. The hybrid design pulls such accounts at read time instead.

At read time, the reader's service fetches the account's latest photo entries. It merges them into the pushed feed by time.

Ranking the feed

The feed is ranked, not purely newest first. Feed ranking was taught with the news feed problem.

Ranking scores a short list of recent entries. Signals include recency, likes and comments on the photo.

A photo from a close account can outrank a newer photo from a distant one. That order is the product's choice.

Ranking runs per reader at read time. The candidate list is short, so the scoring stays affordable.

A plain newest-first order remains the fallback. Ranking failure degrades the order, never the feed itself.

Freshness and failure

Pushed entries travel through a queue. A busy queue makes new photos land a moment late.

Pulled entries arrive at read time. They are fresh by construction, at the price of read work.

A lost feed cache rebuilds from photo records of followed accounts. Active users rebuild first.

The feed can serve a slightly older page during any rebuild. Stale beats missing throughout this design.

Deep dive stories and media

Stories reuse the upload and storage design with one sharp difference.

That difference is lifetime. A story is built to disappear, and the design must make disappearance reliable.

Media handling matters more here. Stories are viewed in quick bursts, one after another.

Stories in numbers

Story views reach 500,000,000 a day. That is the stated figure for this problem.

500,000,000 views ÷ 86,400 seconds = 5,787 story views per second.

Viewing is bursty. Morning and evening peaks run well above that average rate.

The read path must absorb bursts without queueing viewers. Caching carries almost all of that load.

A short life by design

A story lives 24 hours. That lifetime is a stated product rule of this design.

Each story record carries its expiry time. The time is set when the story is posted.

Readers check the expiry time on every story they gather. An expired story is filtered out at read time.

A background job deletes expired story media. Deletion can run late without any expired story showing.

In a worked example, 10,000,000 photo stories a day × 200 KB each = 2 TB of story data alive at any moment.

That data leaves again a day later. Story storage stays bounded instead of growing without end.

Media sizes and delivery

Story media is processed into phone-ready sizes at upload. Background jobs do this work.

Stories are viewed in sequence. The client prefetches the next stories while the current one plays.

Prefetching hides delivery latency. The next story is already on the device when the viewer taps forward.

A CDN caches story media near viewers. A popular story is served from cache almost every time.

Where stories break

A famous account's new story draws a burst of views at once. The CDN absorbs the burst from its caches.

Cache misses reach blob storage together. Serving the original sizes keeps that fallback path simple.

The deletion job can fall behind during a burst. Read-time expiry checks keep the product rule intact meanwhile.

A story that fails processing stays hidden. Viewers see the account's other stories, never a broken one.

Evaluate the design

Evaluation is the last step of the interview method.

Every choice in this problem traded one good thing for another. Both sides of each trade matter.

Direct upload to storage gains light app servers. It costs more steps to confirm.

Hybrid fan-out gains fast feed reads. It costs two paths to maintain.

Originals plus sizes gain quality at every size. They cost more storage.

Safety against speed on upload

Upload confirms size and checksum before a photo can appear. Confirmation adds a step to every upload.

That step buys certainty. No feed ever shows a half-written or corrupted photo.

Direct upload to blob storage keeps app servers light. The control path and the byte path stay separate.

Separate paths cost more parts to run. The design accepts that cost for a hot upload path.

Freshness against cost in the feed

Hybrid fan-out keeps feed reads fast. It also keeps two paths running, push for most accounts and pull for large ones.

Ranked order costs compute on every read. Newest first is cheaper and simpler.

The product value sits in the ranking. A feed people enjoy opening is worth the scoring cost.

In normal running, the feed picks latency over perfect freshness. A photo can reach a feed a moment late.

Storage against quality

Keeping the original plus every size costs storage on every photo. Each size is another stored copy.

Keeping three copies of every photo costs 60 TB of new stored data a day.

That storage buys quality at every screen size. It also buys safety, since copies survive a data center loss.

Dropping originals would cut storage sharply. It would also block every future size the product might want.

What the design leaves open

Video stays mostly out of this design. Long video would need the transcoding and rendition ideas from the YouTube problem.

Ranking quality stays a seam. Better scoring can arrive without changing upload, storage or fan-out.

Story lifetime is a product rule, not a technical limit. A different lifetime changes storage maths, not the design shape.

The wrap-up

Direct upload and confirmed storage keep photos safe. Sizes and the CDN keep photo reading fast.

Hybrid fan-out with photo references carries the feed. References stay cheap even though photos are heavy.

The design spends storage to buy quality and safety throughout. That spend is the heart of this problem.

The estimate at a glance