Home › Scenarios › Chat system
System design scenario
Design a chat system (like WhatsApp or Slack)
Intermediate
Half the traffic sends messages, half fetches recent history. One database takes both, and writes alone exceed what a single primary can do.
▶ Simulate this designThe goal
Keep p99 < 150 ms and error rate < 0.10% at 200,000 req/s for 10s.
- Peak load
- 200,000 requests per second
- Traffic mix
- 50% reads, 50% writes
- p99 latency
- under 150 ms
- Error rate
- under 0.10%
The starting architecture
The simulator opens with this design. It is deliberately too weak for the goal: run it and watch which component saturates first.
- Gateway (Load Balancer, 2 instances): WebSocket/HTTP gateway that keeps client connections and forwards requests.
- Chat service (Service, 30 instances): Chat service: validates messages, fans them out and serves conversation history.
- Message store (Database): Message store. Holds every conversation; writes must scale out by sharding.
How to approach it
The hints unlock one at a time in the app. Try the design yourself before reading them.
Show the hints
- Reads and writes have different needs: split them (select an edge → Carries).
- Recent messages are hot: serve history reads from a cache.
- Absorb message writes with a queue so senders get a fast acknowledgement.
- Writes still need a home: shard the message store so the consumers can keep up.
What the simulator shows you
SimLoad models every component as a queue with real capacity, latency, timeouts and retries, so you see utilisation, p50/p99 latency, errors and monthly cost change as you scale. Insights name the bottleneck in plain language, and the capacity planner sizes the fix. A reference solution that meets the goal is verified by automated tests.
▶ Try it in the simulator