Case Study: Design WhatsApp (Real-time Messaging)
Mental Model
Connecting isolated components into a resilient, scalable, and observable distributed web.
Designing a real-time messaging system like WhatsApp or Messenger is a classic system design question. It tests your knowledge of WebSockets, Message Queues, and Consistency Models.
1. Requirement Clarification
Functional
- 1-on-1 and Group chats.
- Online/Offline status (Presence).
- Message read/delivery receipts.
- (Bonus) Media sharing.
Non-Functional
- Low Latency: Sub-100ms delivery.
- Reliability: No messages should be lost.
- Availability: High availability for connection servers.
2. High-Level Architecture
- Client: Maintains a persistent connection to the server.
- Chat Service: Orchestrates message delivery.
- Presence Service: Tracks which users are online.
- Notification Service: Pushes messages to offline users.
3. Persistent Connections: WebSockets vs. HTTP
- HTTP Long Polling: Wasteful, high overhead.
- WebSockets: Standard for real-time. Full-duplex communication over a single TCP connection.
4. Scaling the Presence Service
Instead of updating a DB on every "Heartbeat," use a Redis-based cache. A user's online status is a key in Redis with a TTL of 30 seconds.
5. Message Storage (Cassandra)
Chat data is "Wide Column" and time-series in nature. Cassandra is the industry standard for chat history because it supports massive write throughput and efficient range scans for message history.
Final Takeaway
Chat systems are about Maintaining State. The challenge is not sending a message, but tracking millions of active connections and managing the presence of billions of users.
Technical Trade-offs: Messaging Systems
| Pattern | Ordering | Durability | Throughput | Complexity |
|---|---|---|---|---|
| Log-based (Kafka) | Strict (per partition) | High | Very High | High |
| Memory-based (Redis Pub/Sub) | None | Low | High | Very Low |
| Push-based (RabbitMQ) | Fair | Medium | Medium | Medium |
Key Takeaways
- 1-on-1 and Group chats.
- Online/Offline status (Presence).
- Message read/delivery receipts.
Production Readiness Checklist
Before deploying this architecture to a production environment, ensure the following Staff-level criteria are met:
- High Availability: Have we eliminated single points of failure across all layers?
- Observability: Are we exporting structured JSON logs, custom Prometheus metrics, and OpenTelemetry traces?
- Circuit Breaking: Do all synchronous service-to-service calls have timeouts and fallbacks (e.g., via Resilience4j)?
- Idempotency: Can our APIs handle retries safely without causing duplicate side effects?
- Backpressure: Does the system gracefully degrade or return HTTP 429 when resources are saturated?
Read Next
Verbal Interview Script
Interviewer: "How would you ensure high availability and fault tolerance for this specific architecture?"
Candidate: "To achieve 'Five Nines' (99.999%) availability, we must eliminate all Single Points of Failure (SPOF). I would deploy the API Gateway and stateless microservices across multiple Availability Zones (AZs) behind an active-active load balancer. For the data layer, I would use asynchronous replication to a read-replica in a different region for disaster recovery. Furthermore, it's not enough to just deploy redundantly; we must protect the system from cascading failures. I would implement strict timeouts, retry mechanisms with exponential backoff and jitter, and Circuit Breakers (using a library like Resilience4j) on all synchronous network calls between microservices."