Skip to content
System Designer

Medium · Social and messaging

Disappearing stories

People post photos and short clips that vanish after 24 hours. Followers tap through a tray of stories every day, and the poster sees who looked. Deleting on time matters: storage must not grow forever. Practise this medium system design problem for free with a Google or GitHub account.

The brief

People post photos and short clips that vanish after 24 hours. Followers tap through a tray of stories every day, and the poster sees who looked. Deleting on time matters: storage must not grow forever.

Think of 24-hour stories.

Users, scale and requirements

Who uses it
5 million people a month
Audience in plain numbers
5,000,000 people per month
Normal peak
≈ 3,000 requests per second
Request mix
Read: 67%; Stream chunk: 10%; Upload: 2%; Write: 3%; Analytics event: 18%
Speed for 99 of 100 requests
Read: ≈ 450 ms; Stream chunk: ≈ 1,000 ms; Upload: ≈ 5,000 ms; Write: ≈ 450 ms
Successful requests
99.8%
Data safety
At most 1 minute of writes may be lost.
Monthly budget
≈ $78,000
Data at rest
≈ 120 TB
Where users are
North America: 40%; Europe: 30%; Asia Pacific: 30%
Home region
North America
Waiting deadlines
Read: 900 seconds; Stream chunk: 900 seconds; Upload: 3,600 seconds; Write: 3,600 seconds; Analytics event: 3,600 seconds
Maximum retained history
1 day
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.
Personal reads
30% of reads are private; a shared public copy cannot answer them.

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

  • Each story is about 3 MB in total (approx.).
  • Stories are deleted after 24 hours. Storage depends on how well you expire them.
  • Scored file retention is at most 1 day. Production visibility must also check expiry on reads; deleting a file later does not hide a cached copy.

Questions that shape the design

What happens at hour 24?

The story must stop being visible and the files should be deleted soon after to save money.

Who sees the "seen by" list?

Only the poster. Every view tap is an event that has to be recorded, though it can arrive a few seconds late.

Is a story a hot item?

Sometimes. A celebrity story can be viewed by millions in an hour. Most stories are seen by a few friends.

Do stories have to be kept for anyone later?

No. They disappear for everyone, which makes the storage story easy: nothing is kept forever.

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 19:00 · Viral spike

    A post blows up. Traffic climbs to several times normal within minutes.

    Traffic reaches 5 times the scheduled load; rises over 600 seconds, holds for 3,600 seconds and eases over 3,600 seconds.

  2. 13:00 · Cost blowout

    A crawler hits uncached pages all day, and every pay-per-use part of the bill multiplies.

    Traffic for Read, Search reaches 1.5 times the scheduled load; rises over 600 seconds, holds for 21,600 seconds and eases over 600 seconds. Other request types keep their scheduled load. Billed usage multiplier: 3. Duration: ≈ 21,600 seconds.

What a strong design has to handle

  • What makes this storage cheaper than a photo app? Think about what happens to a story after one day.
  • Enforce story expiry on reads and eventually remove every retained copy.
  • A retention rule makes storage flat, but it also makes deletion permanent. A "save my story" feature needs a separate copy.
  • A one-hour CDN cache keeps the bandwidth bill low, but a story deleted early can stay visible for a while. Short caches cost more and are safer.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

Related problems