Get an invite

Design a chat appSystem design interview practice, out loud

A voice interviewer that follows your reasoning, on a canvas you both see. Here is the brief, the numbers you can ask for, and what the interview goes into.

  • System design
  • 30 or 45 minutes
  • Open at every level
Practise this one out loud

Private beta · 30 free minutes when you're in

A desktop browser and a microphone.

The brief

The interviewer reads it out, then waits for you.

Interviewer
“Design a chat app. People send text messages to each other from a phone or a laptop. A message sent to someone who is offline is waiting for them when they come back, and the sender can see whether it has been delivered. Start wherever you like; the canvas is yours.”

The numbers you can ask for

The interviewer answers these when you ask, and never volunteers them. For anything else it says the brief doesn't fix that: choose an assumption and say it out loud.

You askThe interviewer answers
How many users?100 M daily active users
How many messages?4 B messages a day; peaks at 3× the average
How many are online at once?~10 M online at once at peak
How big is a message?Text only, ~100 bytes average, 4 KB max
How fast must a message arrive?Under 500 ms to an online recipient; 99 in 100 under 1 s
How long is history kept?Indefinitely; users scroll back through any chat
How big is a group?Up to 200 members; most under 10
How many devices per user?A phone plus up to 4 laptops or tablets, same chats on each
Availability?Sending 99.99 %; a message the sender saw as sent is never lost
Is X in scope?In: one-to-one text, group chats, delivery to offline users, sent/delivered/read status. Out: photos and files, voice and video calls, search, bots

Be ready for these

The interviewer starts with the requirements and ends with the wrap-up. In between, it follows you, so the order is yours. The answers are yours too: this page doesn't give them.

  1. What exactly are you building, and what numbers must it hold?First
  2. How does a message get from one online device to another?
  3. Where do messages live, and how is a conversation read back?
  4. How do people who were offline get their messages, and what does the sender see?
  5. What changes for groups, for several devices, and for keeping one order?If there's time
  6. Where is your design weakest, and what would you build first?Last
  7. Can someone follow your canvas without you there to explain it?Throughout

What's expected at your level

Your Report reads you against the bar for the level you pick. Each level keeps what's below it and adds a line.

See all twelve bars →
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • Judged only if the interviewer asks about it, at Junior.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • Judged only if the interviewer asks about it, at Junior.
Consistency and async

Not judged at Junior.

Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
Technical depth
  • Explains what one technology does in the design, and why it fits.
Operability

Not judged at Junior.

Communication
  • On the final canvas, every box is named and joined to its flow.
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
Consistency and async
  • Says which work happens later and what starts it, and what the user is told, and when.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
Operability
  • Names a metric for the main path, and the value that should alert someone.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
  • +Sets a target (a latency, an availability) and names the part of the design it constrains.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
  • +Sizes both sides: a figure for the writes and a figure for the reads.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
  • +Gives every use case in the brief a path.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
  • +Chooses the store by how it is looked up.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
  • +Puts a cache or a CDN on the busy path and says what it holds, or shows none is needed.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
  • +Handles a second failure, in a different part of the design.
Consistency and async
  • Says which work happens later and what starts it, and what the user is told, and when.
  • +Says how the client learns the work finished, or how stale a value may be.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
  • +Says when their choice would stop being right, and what they would change then.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
  • +Does the same for a second mechanism, elsewhere in the design.
Operability
  • Names a metric for the main path, and the value that should alert someone.
  • +Says how a change rolls out safely.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
  • +Walks the whole design once, near the end.
Scoping
  • Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
  • +Names something that is out, and sizes the reads and the writes separately.
  • +Sets a target (a latency, an availability) and names the part of the design it constrains.
  • +Names the requirement that would change the architecture, and what would change.
Estimation
  • Turns one given number into a new figure, out loud, and uses a number to justify one choice.
  • +Says the unit, and uses a figure they worked out to size a named component.
  • +Sizes both sides: a figure for the writes and a figure for the reads.
  • +Names the figure that limits the design, and says why.
Solution design
  • Connects a client, a service and a store, and walks one use case through them.
  • +Walks two use cases end to end, and says what each component is for.
  • +Gives every use case in the brief a path.
  • +Names the part that changes first as the system grows, and what it becomes.
Data and interfaces
  • Says what is stored and in what kind of store, and one field kept beside the content.
  • +Says why the store fits what it holds, and names one API call with its inputs and output.
  • +Chooses the store by how it is looked up.
  • +Says how the schema or an API changes without breaking clients.
Scalability
  • Treats reads and writes as separate paths, and says which one is busier.
  • +Says how the busier path scales out.
  • +Puts a cache or a CDN on the busy path and says what it holds, or shows none is needed.
  • +Names what fails first at ten times the load, and the fix.
Reliability
  • Says what happens when a named part fails, and one way the system recovers.
  • +Says what happens to the work in flight, and a concrete limit on the recovery.
  • +Handles a second failure, in a different part of the design.
  • +Says how a failure is kept from spreading, and what keeps working meanwhile.
Consistency and async
  • Says which work happens later and what starts it, and what the user is told, and when.
  • +Says how the client learns the work finished, or how stale a value may be.
  • +Says what happens when that work fails or runs twice.
Trade-offs
  • Names an alternative to one choice, and a reason tied to the problem.
  • +Gives a reason specific to this system, and names what their own pick costs.
  • +Says when their choice would stop being right, and what they would change then.
  • +Names the decision that is hardest to reverse, and why.
Technical depth
  • Explains what one technology does in the design, and why it fits.
  • +Explains how one mechanism works inside, and one of its limits.
  • +Does the same for a second mechanism, elsewhere in the design.
  • +Shows how one of those limits shaped a choice.
Operability
  • Names a metric for the main path, and the value that should alert someone.
  • +Says how a change rolls out safely.
  • +Says how cost is watched or kept in bounds.
Communication
  • On the final canvas, every box is named and joined to its flow.
  • +Talks while drawing: names each box as it goes down.
  • +Walks the whole design once, near the end.
  • +Answers each question in its first sentence, then gives the detail.

Thirty minutes. Out loud. On this brief.

Pick your level when you start. Pause for coaching if you get stuck, and read your Report a few minutes after.

Private beta · 30 free minutes when you're in

Other interviews

System design · 30 min · Junior, Mid

Design a URL shortener

Someone pastes a long link and gets a short one back; anyone who opens the short link lands on the original page.

System design · 30 or 45 min · Mid to Staff

Design a video platform

People upload a video from a phone or a laptop, and anyone can watch it — on a slow connection, on a TV, anywhere in the world.