Step 3: High-Level Design

From Numbers to Architecture

You have your requirements from Session 6.1. You have your scale estimates from Session 6.2. Now you translate both into a diagram. The high-level design (HLD) is the skeleton of your system. Every box represents a component. Every arrow represents data flow. Every component exists because a requirement or a scale constraint demands it.

The HLD is not a wish list of technologies. It is a structural argument. Each component answers a question: what problem does it solve, and why can the adjacent components not solve that problem on their own?

The Standard Components

Most large-scale systems share a common set of building blocks. You do not include all of them in every design. You include the ones your requirements demand.

High-Level Design: Chat Application

Building on the WhatsApp example from Sessions 6.1 and 6.2, here is the HLD for a one-to-one chat system handling 500M DAU.

Justifying Each Component

Every box in the diagram above has a reason.

WebSocket connections through Load Balancer. Chat requires real-time bidirectional communication. HTTP polling would generate 500M+ unnecessary requests per minute. WebSockets maintain a persistent connection. The load balancer distributes these connections across Chat Service instances.

Chat Service. Handles the core message flow: receive message from sender, determine if recipient is online, deliver or queue for later delivery. This is the heart of the system.

Message Queue (Kafka). At 231K writes/second, writing directly to the database from the Chat Service would create a bottleneck. The queue absorbs write spikes and decouples message ingestion from persistence. If the database is slow for a few seconds, messages queue up instead of being dropped.

Message Store (Cassandra). At nearly 2 PB/year with 3x replication, you need a database designed for high write throughput and horizontal scaling. Cassandra handles this well. We chose it over PostgreSQL for messages because relational features (joins, transactions) are not needed for message storage.

Session Cache (Redis). The Presence Service needs to know instantly whether a user is online and which Chat Service instance holds their WebSocket connection. Redis provides sub-millisecond lookups for this mapping.

Notification Service. When the recipient is offline, the message must still be delivered eventually. The Notification Service handles push notifications (APNs, FCM) to wake the recipient's device.

User Service and PostgreSQL. User profiles, authentication, and contact lists are relational data with low write volume. PostgreSQL is the right fit: ACID transactions for account operations, and the scale is manageable (user profile reads are cacheable).

Defining API Contracts

After the HLD diagram, define the key APIs. You do not need every endpoint, just the ones that serve the core flow.

Send message (WebSocket frame):

{
  "action": "send_message",
  "to": "user_id_456",
  "content": "Hello",
  "timestamp": 1711929600,
  "client_msg_id": "uuid-abc-123"
}

Receive message (WebSocket frame):

{
  "action": "new_message",
  "from": "user_id_123",
  "content": "Hello",
  "timestamp": 1711929600,
  "msg_id": "server-generated-id",
  "client_msg_id": "uuid-abc-123"
}

Fetch message history (REST):

GET /api/v1/conversations/{conversation_id}/messages?before={msg_id}&limit=50

Notice the client_msg_id in the send message payload. This is an idempotency key. If the client sends the same message twice (due to a network retry), the server can deduplicate using this ID. This small detail shows the interviewer you think about real-world reliability.

HLD Presentation Tips

Draw top to bottom or left to right. Clients at the top, storage at the bottom. Data flows downward. This is the convention interviewers expect.

Label the arrows. An arrow without a label is ambiguous. Does data flow from service A to service B via HTTP, gRPC, or a message queue? Label it.

Start simple, then elaborate. Draw the minimal HLD first (client, server, database). Then add components one by one as you explain why each is needed. This builds a narrative. It is far more effective than presenting a complex diagram all at once and then trying to explain it.

Separate the read path from the write path. In many systems, reads and writes follow different paths through the architecture. Making this explicit shows depth. For the chat system: the write path goes Client to Chat Service to Kafka to Cassandra. The read path for message history goes Client to Chat Service to Cassandra (or Cache).

Further Reading

• System Design Interview, Vol. 1 by Alex Xu, Chapter 12: Design a Chat System
• Facebook Engineering: Building Mobile-First Infrastructure for Messenger
• InfoQ: The WhatsApp Architecture Facebook Bought for $19 Billion
• Martin Fowler: Richardson Maturity Model (API design levels)