Design a large-scale mobile messaging platform where billions of users send text messages, media, and voice messages in 1-on-1 and group chats, with end-to-end encryption, delivery and read receipts, typing indicators, message/user search, and offline message delivery — similar to WhatsApp.
Start with the simplest possible design — one server handles all connections and message delivery. Understand why a single server with in-memory routing immediately breaks down at scale and what the core challenges of messaging systems are.
Split the monolith into a stateless Chat Gateway (WebSocket connections only) and a separate Message Service. Introduce a DNS/routing layer so clients are geo-routed to the nearest region before hitting a Load Balancer. Externalise presence (who is online and on which server) to Redis. Use Cassandra as the Message Store for write-heavy time-series message data.
Introduce a multi-topic Kafka queue to decouple message ingestion from delivery. Add a Fan-out Worker to handle group message delivery to N recipients asynchronously. Understand the write amplification problem in group chats and how to manage it.
Add media upload and delivery via Object Storage and CDN with pre-signed URLs. Route media processing through its own Kafka topic so transcoding never blocks message delivery. Implement delivery and read receipts as a separate lightweight event stream. Understand why media must never flow through the messaging server.
Assemble the complete production architecture: a DNS/routing layer geo-routes clients; the Chat Server (WebSocket) and a merged Application Server (REST API — auth, send, group/user management, search) sit behind the Load Balancer; a dedicated Online Presence Service and a general-purpose Cache both run on their own Redis Clusters; a multi-topic Kafka queue (backed by a Kafka Cluster) feeds a pool of specialized Worker Services — Message Delivery, Push Notification, Media Processing, Search Indexing, and Analytics — each scaled and failing independently; a Search Index (Elasticsearch) enables message/user/group search; a User Database (MySQL) and Message Database (Cassandra) each run with read replicas; and Rate Limiting, Monitoring & Logging, and an Analytics/Data Warehouse round out the operational picture. Understand why splitting one fan-out worker into five single-purpose workers is the final step in isolating failure domains.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own: