Design a photo feed

Question 1

Who calls this system?

Accepted Answer

The feed is a client-driven read. Start from the caller.

Question 2

What does the app connect to?

Accepted Answer

A gateway in front of the services is where authentication and rate limiting live, and what lets the services behind it scale independently.

Question 3

Reading a feed and posting a photo are very different jobs. Are they the same service?

Accepted Answer

Posting is write-heavy, bursty and tolerant of a second of delay. Reading is constant, latency-sensitive and cacheable. Splitting them lets you scale and fail them separately.

Question 4

An account with two million followers posts. What happens on that request?

Accepted Answer

Fanning out to millions of follower feeds inside the POST is how the upload times out. The write records the post and hands the fan-out to a queue; the work happens behind it, and a spike becomes a backlog instead of an outage.

Question 5

Where does an assembled feed live between requests?

Accepted Answer

Rebuilding a feed from the posts table on every open is the expensive way to answer the same question ten times a day. Materialised feeds in a cache are what make the read path cheap.

Question 6

Where do posts themselves live?

Accepted Answer

The cache holds a view of the truth. Something has to hold the truth.

Question 7

Where do the photos go?

Accepted Answer

Image bytes do not belong in your database or on your service disks. Object storage behind a CDN keeps them off your read path entirely — the feed carries URLs, not pixels.

Question 8

Your client reaches the store directly. Who decides what it may see?

Accepted Answer

A feed is a permissioned view — who you follow, what is private, what is blocked. A client with a direct line to the store bypasses all of it.

Question 9

How many feed reads a second are you designing for?

Accepted Answer

50M users opening the feed 10 times a day is 500M reads a day, or roughly 5,800 a second on average — call it three to four times that at peak. Next to ~58 posts a second, this is what tells you the whole design should be arranged around reads.

Blueprint — system design