Networking & Traffic Management
Service Communication Protocols
REST, gRPC, WebSockets, and GraphQL each trade off human-readability, performance, and coupling differently — the right choice depends on whether the call is internal or client-facing, and whether it needs to be synchronous at all.
- REST over HTTP+JSON: ubiquitous, human-readable, cacheable by standard HTTP semantics, but text parsing and payload verbosity cost bandwidth and CPU at scale
- gRPC: HTTP/2 transport with protobuf binary encoding — compact and fast, supports bidirectional streaming, requires a shared schema (
.proto) — a strong default for internal service-to-service calls - WebSockets: a persistent, bidirectional connection — necessary for real-time push (chat, live feeds), but the connection is stateful, which complicates load balancing (Load Balancing)
- GraphQL: the client specifies exactly the fields it needs in a single request, solving over-/under-fetching — at the cost of query-complexity limits and harder HTTP-level caching at the gateway
- Every synchronous protocol couples the caller's success to the callee's availability in that moment; when that coupling is unacceptable, asynchronous messaging (Message Queues) removes it entirely
| Protocol | Best for | Tradeoff |
|---|---|---|
| REST / HTTP+JSON | Public APIs, browser clients | Verbose payloads, per-request parsing overhead |
| gRPC | Internal service-to-service calls | Requires shared .proto schema, less human-debuggable |
| WebSockets | Real-time bidirectional push | Stateful connection, harder to load balance |
| GraphQL | Clients with varied, precise data needs | Query complexity control and caching are harder |