Protocols & Communication

Above the network, the protocol choice decides your latency floor, your failure modes, and how easy the thing is to debug.

TCP vs UDP. TCP is connection-oriented: it orders bytes, retransmits what is lost, and backs off under congestion. That reliability costs a handshake and head-of-line blocking — one lost packet stalls everything behind it. UDP has none of it, which is exactly why real-time video, games, and DNS use it. Losing a frame of video is better than pausing to redeliver it.

HTTP versions. HTTP/1.1 allows one in-flight request per connection in practice, so browsers open several. HTTP/2 multiplexes many streams over one connection and compresses headers, but because it still rides TCP, one lost packet stalls every stream. HTTP/3 moves to QUIC over UDP, so loss on one stream no longer blocks the others, and the handshake is faster.

Choosing an API protocol. REST over HTTP is the default: cacheable, debuggable with curl, universally supported. gRPC uses HTTP/2 and protobuf — compact, fast, strongly typed, with real streaming, and awkward from a browser without a proxy, which makes it a service-to-service choice. GraphQL lets the client ask for exactly the fields it needs, solving over-fetching for many different clients, at the cost of harder HTTP caching and a standing N+1 risk in resolvers.

Pushing to the client. WebSockets give a persistent full-duplex connection, right for chat and collaborative editing. Server-Sent Events are one-directional server-to-client over plain HTTP with automatic reconnect — simpler, and enough for notifications, progress, and token streaming. Long polling is the fallback when neither is available.