Skip to content
System Designer

Medium · Social and messaging

One-to-one chat

People send short messages to each other from their phones. A message must arrive once, in order, even when the phone is on a bad connection and sends it again. If the other person is offline, the message waits and a notification goes out. Practise this medium system design problem for free with a Google or GitHub account.

The brief

People send short messages to each other from their phones. A message must arrive once, in order, even when the phone is on a bad connection and sends it again. If the other person is offline, the message waits and a notification goes out.

Think of a chat app like WhatsApp.

Users, scale and requirements

Who uses it
10 million people a month
Audience in plain numbers
10,000,000 people per month
Normal peak
≈ 20,000 requests per second
Request mix
Message: 55%; Sync change: 15%; Read: 10%; Analytics event: 10%; Sign-in: 2%; Notification: 8%
Speed for 99 of 100 requests
Message: ≈ 300 ms; Sync change: ≈ 400 ms; Read: ≈ 400 ms; Sign-in: ≈ 1,000 ms
Successful requests
99.9%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $60,000
Data at rest
≈ 30 TB
Where users are
North America: 30%; Europe: 30%; Asia Pacific: 40%
Home region
North America
Waiting deadlines
Message: 900 seconds; Sync change: 900 seconds; Read: 900 seconds; Analytics event: 3,600 seconds; Sign-in: 900 seconds; Notification: 900 seconds
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.
Personal reads
95% 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.

  • A message is about 1 KB (approx.).
  • A delivery receipt ("delivered", "read") counts as an event.
  • Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.

Questions that shape the design

What if the phone loses signal mid-send?

The app retries. The message must still arrive exactly once.

What if the other person is offline?

Save the message and send a push notification. They get it when they open the app.

Can a message ever be lost?

Never. Once the app shows one tick, the message is safe on your side.

What happens in the morning?

Millions of phones wake up and reconnect in the same minute and ask what they missed.

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. 08:00 · Synchronized rush

    Many callers send requests together instead of spreading them over time.

    Traffic for Sign-in, Message, Read, Sync change reaches 10 times the scheduled load; rises over 10 seconds, holds for 60 seconds and eases over 300 seconds. Other request types keep their scheduled load.

  2. 14:00 · Zone outage

    An availability zone loses power or network access.

    Duration: ≈ 3,600 seconds.

  3. 19:00 · Duplicate delivery

    The queue redelivers messages. Without duplicate protection, side effects may be applied twice.

    Affected share: 1%. Duration: ≈ 3,600 seconds.

What a strong design has to handle

  • What stops the same message from showing up twice when the phone retries?
  • Recover durable ordered messages across retries and disconnected recipients.
  • Storing each message in three zones before saying "sent" costs a few milliseconds but means a failed building loses nothing.
  • The idempotency store adds one quick lookup per message. It is the price of "never twice".

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