Skip to content
Case study 3

A news feed

A social app shows each user a feed of posts from the people they follow. This design keeps a ready-made feed per user: when someone posts, the post is copied into each follower's feed (fan-out on write), so loading a feed is one quick read.

Here every post goes to ten followers, so one post is ten writes. Nine requests in ten load a feed; one in ten is a new post.

Right now the app servers make all ten writes before telling the poster it worked, so posting is slow, and those writes crowd out feed reads at the database.

Make posting feel instant and feeds load fast. A follower seeing a post a moment late is fine; losing it is not. Keep the app's fan-out at 10: the product needs every follower to get the post.

Requirements

  • Load a user’s feed (a read): 90% of 4,000 requests a second.
  • Post (a write), copied into 10 followers’ feeds.
  • The poster waits only for the post to be safely stored, not for every copy.
  • A feed may lag a new post briefly (a small share of stale reads is fine), but no post may be lost.

Traffic

4K requests a second, 90% reads

50K distinct keys, a few of them very hot

Targets

  • At least 4K successful requests a second
  • p99 latency at most 50 ms
  • Write p99 latency at most 25 ms
  • At most 1% of requests fail, time out or are rejected
  • At most 5% of reads are stale
  • Costs at most $1,200 a month
Next case: A chat service

Components

  • Clients, Clients: 4K req/s, 90% reads
  • Load balancer, Load balancer: round robin
  • App servers, App servers: 4 × app, 8 workers
  • Database, Database: primary only

Connections

  • Clients to Load balancer: requests
  • Load balancer to App servers: spread
  • App servers to Database: reads & writes

Select a component in the diagram to change its settings and connections, or add one above.

Check the design

Runs 10 simulated seconds of the case’s traffic, and checks every target.

Showing a solution replaces your design on screen until you switch back.