Why understanding protocols enables design decisions in HLD - Design It to Understand It

Design: Protocol-Aware System Design

In scope: Protocol characteristics and their impact on design decisions. Out of scope: Deep protocol implementation details or network hardware specifics.

Functional Requirements

FR1: Explain how different communication protocols impact system design choices

FR2: Show examples of protocol selection affecting scalability, latency, and reliability

FR3: Demonstrate how protocol understanding guides component interaction and data flow

Non-Functional Requirements

NFR1: Focus on common protocols like HTTP, TCP, UDP, gRPC, WebSocket

NFR2: Consider typical system scale of 10,000 concurrent users

NFR3: Target API response latency under 200ms p99

NFR4: Availability target of 99.9% uptime

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Load Balancer

Service-to-service communication modules

Caching layers

Message queues or event buses

Databases and storage systems

Design Patterns

Request-response vs. event-driven communication

Synchronous vs. asynchronous protocols

Use of streaming protocols for real-time data

Protocol layering and fallback strategies

Reference Architecture

Client
  |
  | HTTP/HTTPS (REST or gRPC)
  v
API Gateway / Load Balancer
  |
  | gRPC or HTTP for internal services
  v
Microservices Cluster
  |
  | TCP for database connections
  v
Databases / Cache

Optional:
  |
  | WebSocket for real-time updates
  v
Clients (browsers, apps)

Components

API Gateway

Nginx, Envoy

Handles incoming client requests using HTTP/HTTPS, routes to internal services

Microservices

gRPC, HTTP/REST

Internal communication using efficient protocols for low latency and scalability

Message Queue

Kafka, RabbitMQ

Asynchronous communication for decoupling and reliability

Database

PostgreSQL, Redis

Stores persistent and cached data accessed over TCP

WebSocket Server

Socket.IO, native WebSocket

Supports real-time bidirectional communication with clients

Request Flow

1. Client sends HTTP request to API Gateway

2. API Gateway routes request to appropriate microservice using gRPC

3. Microservice processes request, queries database over TCP

4. If real-time update needed, microservice pushes data via WebSocket

5. Microservice may publish events to message queue for asynchronous processing

6. Response sent back through API Gateway to client

Database Schema

Entities: User, Session, Event, Message Relationships: - User 1:N Session - Session N:1 User - Event N:1 User - Message N:1 Event Supports storing user data, session info, events for real-time updates, and messages for asynchronous processing

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure under high load

Microservice communication latency increasing with more services

Database connection limits and query performance degradation

Message queue throughput bottlenecks

WebSocket server handling many concurrent connections

Solutions

Use multiple API Gateway instances with load balancing and health checks

Adopt service mesh for optimized service-to-service communication

Implement database sharding and connection pooling

Scale message queue clusters and partition topics

Use horizontal scaling and sticky sessions for WebSocket servers

Interview Tips

Time: Spend 10 minutes explaining protocol characteristics and their impact, 15 minutes designing the architecture with protocol choices, 10 minutes discussing scaling and trade-offs, 10 minutes for Q&A.

Show understanding of protocol strengths and weaknesses

Explain how protocol choice affects latency, reliability, and scalability

Demonstrate clear data flow with protocol usage at each step

Discuss fallback and hybrid protocol strategies

Address bottlenecks with protocol-aware scaling solutions

Practice

1. Why is it important to understand communication protocols when designing a system?

easy

A. Because protocols control the system's power consumption directly

B. Because protocols determine the color scheme of the user interface

C. Because protocols define how different parts of the system talk to each other

D. Because protocols decide the hardware brand used in the system

Solution

1. Step 1: Understand the role of protocols in communication

   Protocols set rules for data exchange between system components, ensuring they understand each other.

2. Step 2: Connect protocol understanding to design decisions

   Knowing protocols helps choose the right communication method, improving system integration and reliability.

3. Final Answer:

   Because protocols define how different parts of the system talk to each other -> Option C

4. Quick Check:

   Protocols = communication rules [OK]

Hint: Protocols are communication rules between system parts [OK]

Common Mistakes:

• Confusing protocols with UI design
• Thinking protocols control hardware brands
• Assuming protocols manage power directly

2. Which of the following is a correct example of a protocol used in system design?

easy

A. HTML

B. HTTP

C. CSS

D. JPEG

Solution

1. Step 1: Identify protocols among options

   HTTP is a protocol for communication on the web; HTML and CSS are markup and style languages, JPEG is an image format.

2. Step 2: Confirm the correct protocol

   HTTP defines how messages are formatted and transmitted, making it a true protocol.

3. Final Answer:

   HTTP -> Option B

4. Quick Check:

   HTTP = protocol [OK]

Hint: Protocols define communication, not file formats or styles [OK]

Common Mistakes:

• Confusing HTML or CSS as protocols
• Thinking JPEG is a protocol
• Mixing file formats with communication rules

3. Consider a system where a client sends a request using HTTP/2 protocol. What is a key advantage of HTTP/2 over HTTP/1.1 in system design?

medium

A. HTTP/2 allows multiple requests and responses to be multiplexed over a single connection

B. HTTP/2 removes the need for encryption in communication

C. HTTP/2 requires separate connections for each request

D. HTTP/2 only supports text data, not binary

Solution

1. Step 1: Understand HTTP/2 features

   HTTP/2 supports multiplexing, allowing multiple requests and responses simultaneously over one connection.

2. Step 2: Compare with HTTP/1.1 limitations

   HTTP/1.1 requires separate connections or sequential requests, causing delays; HTTP/2 improves efficiency.

3. Final Answer:

   HTTP/2 allows multiple requests and responses to be multiplexed over a single connection -> Option A

4. Quick Check:

   HTTP/2 multiplexing = better performance [OK]

Hint: HTTP/2 multiplexes requests on one connection [OK]

Common Mistakes:

• Thinking HTTP/2 removes encryption
• Believing HTTP/2 needs separate connections
• Assuming HTTP/2 supports only text data

4. A system uses TCP for communication but experiences frequent connection drops. Which protocol-related issue is most likely causing this?

medium

A. TCP is connection-oriented and requires reliable handshakes; network instability can cause drops

B. TCP does not guarantee message order, causing confusion

C. TCP is a stateless protocol, so it cannot maintain connections

D. TCP automatically retries without limits, causing overload

Solution

1. Step 1: Recall TCP characteristics

   TCP is connection-oriented and requires a handshake to establish connections reliably.

2. Step 2: Link network instability to connection drops

   If the network is unstable, TCP connections can drop because handshakes or data packets fail.

3. Final Answer:

   TCP is connection-oriented and requires reliable handshakes; network instability can cause drops -> Option A

4. Quick Check:

   TCP connection needs stable network [OK]

Hint: TCP needs stable network for connection [OK]

Common Mistakes:

• Thinking TCP is stateless
• Believing TCP does not guarantee order
• Assuming TCP retries cause overload

5. You are designing a real-time chat application. Which protocol choice best supports low latency and reliable message delivery, and why?

hard

A. Use HTTP/1.0 because it is the simplest protocol

B. Use FTP protocol because it is designed for file transfers

C. Use SMTP protocol because it handles email sending

D. Use WebSocket protocol because it provides full-duplex communication over a single TCP connection

Solution

1. Step 1: Identify protocol needs for real-time chat

   Real-time chat requires low latency and continuous two-way communication.

2. Step 2: Evaluate protocol options

   WebSocket supports full-duplex communication over one TCP connection, enabling instant message exchange. FTP and SMTP are for file and email transfer, not real-time chat. HTTP/1.0 is outdated and not optimized for persistent connections.

3. Final Answer:

   Use WebSocket protocol because it provides full-duplex communication over a single TCP connection -> Option D

4. Quick Check:

   WebSocket = real-time full-duplex [OK]

Hint: WebSocket enables real-time two-way chat [OK]

Common Mistakes:

• Choosing FTP or SMTP for chat
• Picking HTTP/1.0 for real-time needs
• Ignoring full-duplex communication benefits