Skip to content

Communication (TCP, UDP, RPC, REST)

HTTP (Hypertext Transfer Protocol)

A method for encoding and transporting data between client and server. It's a request/response protocol: clients issue requests, servers issue responses with content and status info. HTTP is self-contained, so requests/responses can flow through intermediate routers and servers (load balancing, caching, encryption, compression).

A request = a verb (method) + a resource (endpoint).

Verb Description Idempotent* Safe Cacheable
GET Reads a resource Yes Yes Yes
POST Creates a resource or triggers a process No No Yes (if freshness info)
PUT Creates or replaces a resource Yes No No
PATCH Partially updates a resource No No Yes (if freshness info)
DELETE Deletes a resource Yes No No

* Can be called many times without different outcomes.

HTTP is an application-layer protocol relying on lower-level TCP and UDP.

TCP (Transmission Control Protocol)

A connection-oriented protocol over IP. Connection is established/terminated with a handshake. Packets are guaranteed to arrive in order and uncorrupted via:

  • Sequence numbers and checksums per packet.
  • Acknowledgements and automatic retransmission.

If the sender gets no correct response, it resends. Multiple timeouts → connection dropped. TCP also implements flow control and congestion control. These guarantees add delay and are less efficient than UDP.

High throughput web servers keep many TCP connections open → high memory use. Connection pooling (or switching to UDP) helps.

Use TCP when: you need all data to arrive intact, or want automatic use of network throughput. Examples: web servers, databases, SMTP, FTP, SSH.

UDP (User Datagram Protocol)

Connectionless. Datagrams (like packets) are guaranteed only at the datagram level — they may arrive out of order or not at all. No congestion control. More efficient than TCP (fewer guarantees).

UDP can broadcast to all devices on a subnet (useful for DHCP, where the client has no IP address yet).

Use UDP when: you need lowest latency, late data is worse than lost data, or you want to implement your own error correction. Examples: VoIP, video chat, streaming, real-time games.

TCP vs UDP

TCP UDP
Connection Connection-oriented Connectionless
Delivery Guaranteed, ordered Best-effort, unordered
Overhead Higher (handshake, ACKs) Lower
Use cases Web, DB, SSH VoIP, video, games

RPC (Remote Procedure Call)

A client causes a procedure to execute in a different address space (usually a remote server), coded like a local call — hiding network details. Remote calls are slower/less reliable than local calls, so distinguish them.

Popular frameworks: Protobuf, Thrift, Avro.

Flow: client program → client stub (marshals args) → OS sends → server OS → server stub (unmarshals, calls procedure) → response in reverse.

Sample RPC call:

GET /someoperation?data=anId

POST /anotheroperation
{
  "data": "anId";
  "anotherdata": "another value"
}

RPC focuses on exposing behaviors, often used for internal, performance-sensitive calls.

Choose an SDK/RPC when: you know your platform, want to control how logic is accessed/errored, or performance is the primary concern.

Disadvantages: tight coupling to implementation; new API per operation; hard to debug; may not leverage existing caching/proxies out of the box.

REST (Representational State Transfer)

An architectural style with a client/server model: the client acts on resources managed by the server. Communication must be stateless and cacheable.

Four qualities of a RESTful interface:

  1. Identify resources (URI in HTTP) — same URI regardless of operation.
  2. Change with representations (verbs in HTTP) — use verbs, headers, body.
  3. Self-descriptive errors (status codes) — don't reinvent the wheel.
  4. HATEOAS — the service should be fully accessible in a browser.

Sample REST calls:

GET /someresources/anId

PUT /someresources/anId
{"anotherdata": "another value"}

REST focuses on exposing data, minimizing client/server coupling. Being stateless, it's great for horizontal scaling and partitioning.

Disadvantages: poor fit for non-hierarchical operations; limited verbs; nested resources need multiple round-trips; responses can bloat over time.

RPC vs REST comparison

Operation RPC REST
Signup POST /signup POST /persons
Resign POST /resign DELETE /persons/1234
Read person GET /readPerson?personid=1234 GET /persons/1234
Read person's items GET /readUsersItemsList?personid=1234 GET /persons/1234/items
Add item POST /addItemToUsersItemsList POST /persons/1234/items
Update item POST /modifyItem PUT /items/456
Delete item POST /removeItem DELETE /items/456

Key takeaways

  • RPC = verbs/behaviors (internal, performance). REST = nouns/resources (public, scalable, cacheable).

  • TCP vs UDP is a reliability vs latency trade-off.

  • HTTP sits on top of TCP/UDP and is the workhorse of public APIs.

Common Interview Questions

Design a chat app like WhatsApp

Why it's asked here: messaging requires choosing transport (TCP/WebSocket) and delivery semantics.

Key points to discuss:

  • Persistent connection (WebSocket over TCP) for low-latency delivery.
  • Why TCP (reliable, ordered) over UDP for messages.
  • Ordered delivery, acks, and offline storage.
  • Presence (online/offline) and group-chat fan-out.
flowchart LR
    A[User A] -->|WebSocket / TCP| S[Chat server]
    B[User B] -->|WebSocket / TCP| S
    S -->|ordered delivery| D[(Message store)]
Design Google Docs (real-time sync)

Why it's asked here: real-time collaboration is a communication protocol problem.

Key points to discuss:

  • WebSocket/TCP for real-time edits; why UDP fits games but not doc sync.
  • Operational transforms (OT) / CRDTs to merge concurrent edits.
  • Client/server communication model and connection recovery.
  • Latency vs consistency when propagating edits.
flowchart LR
    A[User A] -->|WebSocket| S[Sync server]
    B[User B] -->|WebSocket| S
    S -->|OT / CRDT| D[Converged doc]
    D --> A
    D --> B
Design a real-time multiplayer game

Why it's asked here: games force the UDP-vs-TCP decision.

Key points to discuss:

  • UDP for position/state updates (low latency, loss-tolerant).
  • TCP for login, chat, and transactions (reliable).
  • Client-side interpolation/prediction to hide packet loss.
  • When to add your own reliability layer on top of UDP.
flowchart LR
    P1[Player 1] -->|UDP| GS[Game server]
    P2[Player 2] -->|UDP| GS
    P1 -->|TCP| A[Auth / chat]
    GS -->|state| P1
    GS -->|state| P2

Further reading