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