Courses/System Design/Part 2/Application Protocols

Application Protocols

Modern application layer protocols for different communication patterns

🎙️ How Apps Talk Over the Internet

At Layer 7 — the application layer — we define how software systems communicate. Whether it's a browser loading a page, a mobile app syncing data, or a multiplayer game — the protocol you choose shapes latency, scalability, and user experience. Let's explore the most important application protocols: HTTP, REST, GraphQL, gRPC, SSE, WebSockets, WebRTC, and Polling — and understand their strengths, limitations, and ideal use cases.

🌐 HTTP (HyperText Transfer Protocol)

What It Is

The backbone of the web. A stateless, text-based protocol that defines how clients request resources from servers.

How It Works

1Client sends a request (e.g., GET /home)
2Server responds with data (e.g., HTML, JSON)
3Each request is independent — no memory of previous ones

Real-World Analogy:

Like ordering food at a counter. You ask, they serve. No memory of past orders.

Strengths:

Simple, universal, cacheable
Works with proxies, firewalls, browsers

Limitations:

One-way only
Not suitable for real-time updates

📦 REST (Representational State Transfer)

What It Is

A design pattern built on HTTP. Treats everything as a resource with a unique URL.

How It Works

GET
read
POST
create
PUT
update
DELETE
remove
Stateless: each request contains all necessary info
Often returns JSON

Real-World Analogy:

Like accessing files in folders. /users/42/orders is like opening a user's order folder.

REST = Fixed Burger Combo
REST = "Give me this resource"

REST = reliable and simple — like driving a well-tuned car

Strengths:

Easy to understand and implement
Scales well with microservices
Works with caching and load balancers

Limitations:

Over-fetching: you get more data than needed
Under-fetching: multiple requests for related data

🧠 GraphQL

What It Is

A query language for APIs that lets clients ask for exactly what they need.

How It Works

Single endpoint (e.g., /graphql)
Clients send structured queries
Server returns only requested fields
Schema defines available types and relationships

Real-World Analogy:

Like ordering à la carte — you choose exactly what goes on your plate.

GraphQL = Build-Your-Own Burger
GraphQL = "Give me exactly these fields"

GraphQL = powerful but demanding — like building a custom engine

Strengths:

Reduces over-fetching and under-fetching
Great for mobile apps and complex UIs
Strong developer tooling

Limitations:

Harder to cache
Requires schema discipline
Overhead for simple use cases

🚀 gRPC (Google Remote Procedure Call)

What It Is

A high-performance protocol for backend communication, built on HTTP/2 and Protocol Buffers.

How It Works

APIs are defined in .proto files
Supports unary and streaming calls
Uses compact binary format for speed

Real-World Analogy:

Like calling a method on a remote object — getUser(id) feels like a local function.

gRPC = "Run this function remotely, like it's local"

Strengths:

Fast, efficient, low latency
Ideal for microservices and internal APIs
Supports bi-directional streaming

Limitations:

Not human-readable
Harder to debug without tooling
Browser support is limited (needs proxy)

🔁 Polling

What It Is

A technique where the client repeatedly asks the server for updates.

How It Works

Client sends requests at intervals (e.g., every 5 seconds)
Server responds with latest data (if any)

Real-World Analogy:

Like checking your mailbox every few minutes to see if a letter arrived.

Polling = "Knocking on the same door again and again"
Polling = REST × N
Polling = GraphQL × N

REST/GraphQL = "The door you're knocking on" | Polling just automates the knocking

Strengths:

Simple to implement
Works with any server

Limitations:

High latency
Wastes bandwidth and server resources
Not scalable for many users

🔄 SSE (Server-Sent Events)

What It Is

A one-way push protocol where the server streams updates to the client over HTTP.

How It Works

Client opens a connection
Server keeps it open and sends updates as events
Only server → client

Real-World Analogy:

Like subscribing to a radio station — you listen, but can't talk back.

Strengths:

Lightweight and easy to use
Great for dashboards and notifications
Works over HTTP (no special setup)

Limitations:

One-way only
Limited browser support
Doesn't work well with proxies that close idle connections

🔗 WebSockets

What It Is

A protocol that enables full-duplex, real-time communication between client and server.

How It Works

Starts as HTTP, then upgrades to WebSocket
Persistent connection
Both sides can send messages anytime

Real-World Analogy:

Like a phone call — both people can talk and listen at the same time.

WebSocket = Phone Call

Strengths:

Low latency
Ideal for chat, games, collaborative tools
Event-driven architecture

Limitations:

Requires connection management
Doesn't work well with traditional HTTP infrastructure
Harder to scale without specialized servers

🎥 WebRTC (Web Real-Time Communication)

What It Is

A protocol for peer-to-peer media and data streaming — especially for audio/video.

How It Works

Uses STUN/TURN servers to establish connections
Supports encrypted media and data channels
Built into modern browsers

Real-World Analogy:

Like a direct walkie-talkie connection between two users — no middleman.

WebRTC = "Direct video call between two browsers — no middleman if possible"

Strengths:

Low latency
Secure and direct
Ideal for video calls, screen sharing, P2P apps

Limitations:

Complex setup (NAT traversal, signaling)
Not suitable for server-based coordination
Harder to debug and monitor

🧠 Summary Table

ProtocolPatternDirectionTransportIdeal For
HTTPRequest-responseClient → ServerTCPWeb pages, basic APIs
RESTResource-basedClient → ServerHTTPCRUD APIs, microservices
GraphQLQuery-basedClient → ServerHTTPFlexible data fetching
gRPCRPC + StreamingBi-directionalHTTP/2Microservices, backend APIs
PollingRepeated requestsClient → ServerHTTPLegacy updates
SSEServer pushServer → ClientHTTPDashboards, notifications
WebSocketsEvent-drivenBi-directionalTCPChat, games, real-time apps
WebRTCP2P media/dataPeer ↔ PeerUDP/TCPVideo calls, screen sharing

🎙️ Closing Thought

Application protocols are the language of distributed systems. Each one offers a different rhythm — from the steady beat of HTTP to the real-time pulse of WebSockets and WebRTC. Choosing the right protocol isn't just about tech — it's about matching your system's communication style to your users' needs.