Communication Protocols
HTTP, WebSockets, SSE, gRPC, REST, and GraphQL
The web is stateless. Every HTTP transaction is brand new - the server doesn’t remember what you just did. This is such a fundamental assumption that we take it for granted, but it shapes everything about how we build systems.
You give HTTP context through headers, cookies, and metadata. This statelessness is actually a feature: it makes HTTP simple, human-readable, and supported by every browser.
But stateless request/response isn’t always what you need.
HTTP
HTTP is the protocol of the internet. It’s request/response by nature - client asks, server answers, connection closes. This simplicity is why it’s everywhere.
The trade-off is overhead. Every request requires a new handshake. For most web traffic, that’s fine. For real-time applications, it becomes a bottleneck.
WebSockets
WebSockets provide bidirectional communication over a persistent connection. Once established, the connection stays open. Both client and server can send messages whenever they want, eliminating the handshake overhead on every message.
This makes WebSockets stateful - they can remember what happened previously. That’s a significant shift from HTTP’s stateless model.
Use WebSockets when you need true real-time bidirectional communication: chat applications, collaborative editing tools, multiplayer games, or any scenario where both sides need to initiate messages.
The cost is complexity. You’re maintaining persistent connections, handling reconnection logic, and managing state.
Server-Sent Events (SSE)
Server-Sent Events are actually older than WebSockets, yet far less commonly used. They provide one-way communication from server to client over standard HTTP.
Many “real-time” features only need server-to-client communication. News feeds, live scores, notifications, status updates - the client doesn’t need to send data back, it just needs to receive updates.
For these use cases, SSE is simpler than WebSockets. You don’t need bidirectional connections, you don’t need special libraries, and it works over standard HTTP infrastructure.
Why aren’t more people using SSE? Browser support was limited in the past. But it’s worth adding to your toolkit.
gRPC
gRPC is fast and uses a strict contract between services. It runs exclusively over HTTP/2 and uses Protocol Buffers for serialisation - not human-readable, but extremely efficient.
Browsers don’t support gRPC natively. You need special libraries and proxies to make it work in a browser context.
This makes gRPC ideal for service-to-service communication where you control both ends. Microservices architectures, IoT devices, low-latency internal APIs - anywhere you need speed and don’t need browser compatibility.
Generally, don’t use gRPC for frontend-to-backend communication. It’s not what it’s designed for.
REST and GraphQL (API Styles Over HTTP)
REST and GraphQL aren’t protocols - they’re architectural styles for building APIs on top of HTTP. Both use standard HTTP requests under the hood; they just differ in how you structure those requests and responses.
You can read more about thei differences here:
Making the Decision
When choosing a protocol, start with these questions.
Is it service-to-service communication where you control both ends? Use gRPC. The performance benefits are worth the setup complexity when browsers aren’t involved.
Does it need to be real-time? If you need bidirectional communication, WebSockets are your answer. But if you only need to push updates from server to client, try SSE first.
For frontend-to-backend APIs, the REST vs GraphQL decision comes down to data complexity. Do you have simple, uniform data needs? REST. Do you have complex data from multiple sources with varied client requirements? GraphQL.
Like posts like this?
You may also like these:
By subscribing, you get a breakdown like this every week.
Free subscribers also get a little bonus:
🎁 The System Design Interview Preparation Cheat Sheet
If you’re into visuals, paid subscribers unlock:
→ My Excalidraw system design template – so you have somewhere to start
→ My Excalidraw component library – used in the diagram of this issue
No pressure though. Your support helps me keep writing, and I appreciate it more than you know ❤️
Brillant breakdown of the tradeoffs here. The part about SSE beeing underused really caught my attention because I've seen so many teams default to WebSockets for push notifactions when they don't actually need bidirectional flow. One thing I've noticed in practice is that SSE also tends to play nicer with existing infrastucture since its just HTTP, which means fewer headaches with load balancers and proxies.