System Design Chapter 10

Communication & Messaging Protocols

Protocol Selection Framework, HTTP Polling vs WebSockets, gRPC Deep-Dive, & AMQP Message Brokers

★ Critical for choosing the right transport mechanism for real-time systems & microservices!

1 Choosing the Right API Protocol

Selecting the optimal communication protocol requires balancing system constraints across six core architectural dimensions:

🧭 API Protocol Selection Framework

🔄 1. Interaction Patterns

Request-Response vs. Real-Time: Is communication synchronous point-in-time querying (HTTP/REST) or continuous bidirectional event streaming (WebSockets, SSE)?

📦 2. Payload Size

Data Volume & Encoding: Large vs small payloads, human-readable text JSON overhead vs compact binary serialization (Protobuf, Avro).

⚡ 3. Performance

Speed & Efficiency: Low-latency thresholds, high throughput (QPS), multiplexed streams over HTTP/2, and minimal CPU/memory parse time.

🔒 4. Security Needs

Authentication & Encryption: TLS in transit, token propagation (OAuth2/JWT), mutual TLS (mTLS) for microservices, and message-level integrity.

🛠️ 5. Developer Experience

Tooling & Documentation: SDK auto-generation, contract schemas (OpenAPI, Proto), debugging inspectability (Postman, DevTools), and ecosystem maturity.

📱 6. Client Compatibility

Browser, Mobile & Legacy: Web browser protocol support, mobile cellular bandwidth/battery constraints, and legacy enterprise systems.

2 Real-Time Communication: HTTP Polling vs. WebSockets

When clients need live updates, choosing between periodic HTTP polling and persistent WebSocket connections impacts latency and bandwidth efficiency significantly.

⏱️ HTTP Polling (Short Polling)Pull-Based

Client sends repeated periodic HTTP requests asking the server if new data is available.

💻 Client ➔ GET /updates ➔ 🖥️ Server

🖥️ Server ➔ 200 OK (data) ➔ 💻 Client

💻 Client ➔ GET /updates ➔ 🖥️ Server

🖥️ Server ➔ 200 OK (no new data) ⚠️ Request Wasted!

💻 Client ➔ GET /updates ➔ 🖥️ Server

🖥️ Server ➔ 200 OK (new data) ➔ 💻 Client

⚠️ Major Disadvantages:

Increased Latency: Updates only received on next interval.
Wasted Bandwidth: Constant HTTP header transfers for empty responses.
Server Resource Overhead: Continual connection opening/closing strains server threads and DB.

⚡ WebSockets (Full-Duplex Socket)Push-Based

Single persistent, bidirectional TCP connection established via an initial HTTP handshake.

💻 Client ➔ WebSocket Handshake (Upgrade) ➔ 🖥️

🖥️ Server ➔ Server Push data ⚡ ➔ 💻 Client

💻 Client ➔ Client message 💬 ➔ 🖥️ Server

🖥️ Server ➔ Server Push data ⚡ ➔ 💻 Client

🛡️ Core Advantages:

Real-Time Data: Instant sub-millisecond push delivery without polling delay.
Reduced Bandwidth: Minimal 2-byte frame overhead per message (no repeated HTTP headers).
Bidirectional Communication: Simultaneous full-duplex messaging over 1 connection.

3 gRPC: High-Performance Type-Safe RPC

gRPC is an open-source high-performance Remote Procedure Call framework developed by Google that leverages HTTP/2 and Protocol Buffers for blazing-fast service-to-service communication.

🚀 gRPC Client-Server Architecture & Pipeline

💻 Client

Client Stubs: Auto-generated language bindings
Type Safety: Compile-time contract enforcement

⚡ Transport & Serialization

HTTP/2 Multiplexing

Protocol Buffers: message { … }

🖥️ Server

Services: Implemented RPC methods
Streaming: Unary & 2-way continuous feeds

🎯 3 Common gRPC Use Cases:

🏢 1. Microservices Architecture

Internal backend-to-backend communication requiring ultra-low latency, binary serialization, and connection multiplexing inside data centers.

🌐 2. Polyglot Systems

Cross-language environments (e.g. Go backend, Python ML service, Java billing engine) sharing identical, strictly-typed .proto contracts.

📡 3. Real-Time Streaming Services

Continuous high-frequency data streams such as live telemetry, IoT sensor feeds, and financial order book streaming.

4 AMQP (Advanced Message Queuing Protocol)

AMQP is an open standard programmable wire protocol designed for enterprise message-oriented middleware (e.g., RabbitMQ), providing reliable asynchronous decoupled messaging.

📬 AMQP Producer ➔ Message Broker ➔ Consumer Architecture

📤 Producer

• Web Services
• Payment Systems

➔ Publish ➔

🏢 Message Broker

🔄 Exchange (Message Routing Engine)

📥 FIFO Queues:m1m2m3m4

➔ Consume ➔

📥 Consumer

• Order Processing
• Notification Systems

🔀 3 Core AMQP Exchange Types:

1 : 1 Direct

Routes messages directly to queues matching an exact routing key (e.g. payment.process).

1 : N Fanout

Broadcasts every message unconditionally to all bound queues, ignoring routing keys.

* Topic (Wildcard)

Routes messages based on wildcard pattern matching (e.g. orders.eu.* or logs.#).

5 Protocol Comparison Matrix

Protocol	Transport	Data Format	Pattern	Best Used For
HTTP / REST	HTTP/1.1 or HTTP/2	JSON / XML (Text)	Request / Response	Public APIs, CRUD operations, Web & Mobile apps
WebSockets	TCP (Full-Duplex)	Text / Binary Frames	Bidirectional Push	Live chats, Collaborative tools, Gaming, Financial tickers
gRPC	HTTP/2 (Multiplexed)	Protocol Buffers (Binary)	Unary + Streaming	Inter-microservice communication, Polyglot systems
AMQP	TCP (Message Broker)	Binary / Any Payload	Pub/Sub & Queues	Asynchronous task queues, Background workers, Event buffering