Skip to content
Case study 4

A chat service

A chat app stores every message in the conversation it belongs to. Sending a message is a write; opening a conversation reads its recent messages.

Chat is unusual: most traffic is writes. Seven requests in ten send a message, and there are 10,000 requests a second at peak.

Read replicas don't help with writes: every write still goes to the one primary. Neither does a bigger machine, past a point: the largest database node takes 64 connections. To go further, split the data. Give each conversation a home on one of several shards, so each primary takes only its share of the writes.

Some conversations are much busier than others (a big group chat), so watch how evenly the load spreads.

Requirements

  • Send a message (a write): 70% of 10,000 requests a second.
  • Open a conversation and read its recent messages (a read): 30%.
  • Messages are stored by conversation; one conversation’s messages live together.
  • Fast for everyone, with nothing dropped.

Traffic

10K requests a second, 30% reads

100K distinct keys, a few of them very hot

Targets

  • At least 9.9K successful requests a second
  • p99 latency at most 60 ms
  • At most 1% of requests fail, time out or are rejected
  • Costs at most $3,000 a month
Next case: A replicated key-value store

Components

  • Clients, Clients: 10K req/s, 30% reads
  • Load balancer, Load balancer: round robin
  • App servers, App servers: 20 × app, 8 workers
  • Database, Database: primary + 1 replica

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.