System Design · Core

Communication Protocols

Pick how services and clients talk: HTTP/REST, gRPC, WebSocket, GraphQL briefly, and sync vs async trade-offs.

1. Start from requirements

Request/response, public API, CRUD → HTTP + REST/JSON Low-latency internal RPC, typed → gRPC Server push, chat, live updates → WebSocket (or SSE) Flexible client-driven queries → GraphQL (with care) Decouple producers, buffer spikes → async messaging

2. HTTP and REST

REST over HTTP uses resources and verbs (GET/POST/PUT/PATCH/DELETE), status codes, and usually JSON. Ubiquitous, cacheable GETs, great for public APIs and browsers.

Principle	Meaning
Stateless	Each request carries auth/context; server does not rely on sticky memory
Resource-based	Nouns in URLs (`/orders/9`), not RPC verbs in the path
HTTP methods	GET read, POST create, PUT replace, PATCH partial, DELETE remove
Uniform interface	Status codes + headers; clients share conventions
Cacheable GETs	Safe methods can use CDN/browser caches when headers allow

Pros: simple, debuggable, CDN/cache friendly for GETs, huge ecosystem.
Cons: chatty for many small resources; JSON verbose; no native bidirectional push.
Interview tip: version APIs (/v1), use idempotency keys on POSTs that matter.

GET /users/42 POST /orders Idempotency-Key: ... PUT /orders/9 full replace PATCH /orders/9 partial update

3. REST vs RPC

	REST (resource HTTP)	RPC (gRPC / JSON-RPC)
Model	Resources + verbs	Procedure calls (`CreateOrder`)
Contract	OpenAPI / conventions	Proto / IDL strongly typed
Caching	Natural for GET	Usually not HTTP-cache friendly
Browser	Native	Needs gateway / grpc-web
Internal services	Fine	Often preferred (latency + types)

4. gRPC

RPC framework over HTTP/2 with Protocol Buffers. Strong contracts (.proto), streaming (unary, server, client, bidi), efficient binary.

Fit	Avoid when
Service-to-service inside mesh	Browser-first public API (need grpc-web/gateway)
Strict schema evolution	Ad-hoc human debugging is the main workflow
Streaming large result sets	Only need simple CRUD JSON

Mention deadlines/timeouts, status codes, and backward-compatible proto field changes (no renumbering).

5. WebSocket

Client <===== persistent TCP/TLS duplex =====> Server - chat messages, presence, collaborative cursors - game state ticks - live notifications (alternative: SSE one-way)

Upgrade from HTTP; then frames both ways.
Sticky or pub/sub needed so any connection server can reach the user (Redis pub/sub, Kafka).
Heartbeats, reconnect with backoff, auth on connect.

6. Server-Sent Events (SSE)

One-way server→client stream over plain HTTP (text/event-stream). The browser EventSource API reconnects automatically. Simpler than WebSocket when the client only needs pushes (live scores, job progress, notification ticks) and still sends commands via normal REST.

Pros: works through many proxies; auto-reconnect; easy auth via cookies/headers on the HTTP request.
Cons: not bidirectional; some proxies buffer; typically HTTP/1.1 connection limits per browser.

7. Long polling

Client opens a request; server holds it until an event arrives or a timeout fires; client immediately opens the next request. Predecessor to SSE/WebSocket — still useful behind restrictive networks.

Client GET /events?since=cursor → (server waits ≤ 30s) ← 200 { events: [...] } or 204 empty Client immediately GETs again Trade-off: more HTTP overhead than WS/SSE; simpler than managing sockets

8. GraphQL (brief)

Client specifies the shape of data in one request. Helps mobile teams avoid over/under-fetching. Costs: complex caching, N+1 resolver risks, and a heavy public schema to secure. Use when product needs flexible queries; do not default to it for every backend.

9. Sync vs async

	Synchronous	Asynchronous
Caller	Waits for result	Enqueues work; continues
UX	Immediate answer	Pending / eventually notified
Failure	Coupled latency and outages	Buffer, retry, DLQ
Examples	Login, price quote	Email, transcoding, fan-out

Sync path: API → User Service → Profile DB → response Async path: API → DB + Outbox → Queue → Workers → side effects

10. Message queues vs synchronous calls

Prefer queues when	Prefer sync RPC/HTTP when
Work can finish later (email, encode)	User needs the answer in this request
Absorb traffic spikes	Latency budget is tight (tens of ms)
Multiple consumers / fan-out	Simple request/response, one dependency
Retries and DLQ are required	Strong immediate consistency across the call

11. Protocol selection summary

Protocol	Direction	Pick when
REST/HTTP	Req/resp	Public APIs, CRUD, cacheable reads
gRPC	Req/resp + streams	Internal typed RPC, low overhead
WebSocket	Bidirectional	Chat, collaborative, games
SSE	Server → client	One-way live updates over HTTP
Long polling	Held req/resp	Fallback when WS/SSE blocked
Message queues	Async	Decouple, buffer, retry side effects

12. How to choose in a design interview

External clients: HTTPS REST (or GraphQL if justified).
Internal fan-out of CPU work: queue + workers.
Live duplex: WebSocket gateway + pub/sub.
One-way server push: SSE (or long poll as fallback).
Tight internal RPC: gRPC with deadlines.

Quick revision

REST: stateless, resource URLs, HTTP methods; default public API.
REST vs RPC: resources/cache vs typed procedures.
gRPC: typed, efficient, streaming; great inside the datacenter.
WebSocket duplex; SSE one-way; long poll as legacy fallback.
Queues when async/spikes/retries; sync when UX needs the answer now.
Always set timeouts/deadlines on remote calls.
Protocol choice follows access pattern, not hype.