Communication Overview

How does the frontend find out that something changed on the backend? There are five common techniques: Short Polling, Long Polling, WebSocket, SSE (Server-Sent Events) and Webhooks. A restaurant makes a good analogy: the dining area is the UI/frontend, the kitchen is the backend, and your order is the data.

1. Short Polling

Concept: the client sends requests to the server at fixed intervals (e.g. every 2–5 seconds) to check whether new data is available.

Restaurant analogy: you keep walking to the kitchen again and again - "Is my order ready now?" "Now?" "Now??"

Key points

• Client controls communication
• Server responds immediately every time (even if nothing changed)
• Most responses are useless ("not ready yet")

Problems

• High number of requests → wastes bandwidth
• Server gets overloaded with unnecessary calls
• Not scalable for real-time systems

When used: simple apps where real-time updates are not critical.

2. Long Polling

Concept: the client sends a request, but the server holds the connection open until data is available.

Restaurant analogy: you go to the kitchen once and stand there until your food is ready. The kitchen says nothing until it’s done.

Key points

• Reduces unnecessary requests
• Server responds only when data is ready
• After the response, the client sends a request again

Problems

• Connection stays open → server resource heavy
• Not true real-time (still a request-response cycle)
• Latency between reconnects

When used: older real-time apps, before WebSockets became popular.

3. WebSocket

Concept: creates a persistent, full-duplex connection (2-way communication) between client and server.

Restaurant analogy: you and the kitchen have a direct walkie-talkie connection. You: "Any update?" Kitchen: "Cooking, done in 2 mins." Kitchen: "Order ready!" - without you asking.

Key points

• One connection stays open
• Both client and server can send messages anytime
• True real-time communication

Advantages

• Very fast (low latency)
• Efficient (no repeated HTTP requests)
• Best for live updates

Use cases: chat apps, live trading apps, multiplayer games, notification systems.

4. SSE (Server-Sent Events)

Concept: the server continuously sends updates to the client over a single connection (one-way only).

Restaurant analogy: the kitchen installs a live display board - "Order #21 cooking", "Order #21 ready". You just sit and watch; no need to ask anything.

Key points

• Only server → client communication
• Uses standard HTTP (simpler than WebSocket)
• Automatically reconnects if the connection drops

Advantages

• Lightweight compared to WebSockets
• Easy to implement
• Great for streaming updates

Limitations

• No client → server communication
• Not suitable for interactive apps

Use cases: live dashboards, news feeds, stock price updates.

5. Webhooks

Concept: a server sends data to another system automatically when an event occurs (no polling needed).

Restaurant analogy: instead of waiting or asking, you give your phone number. The kitchen calls you: "Your order is ready, come pick it up."

Key points

• Event-driven communication
• No repeated requests from the client
• Triggered only when something happens

Advantages

• Most efficient (zero unnecessary calls)
• Real-time without maintaining an open connection
• Scales well

Limitations

• Requires setup (URL endpoints, security)
• Depends on external system availability

Use cases: payment success notifications (Razorpay, Stripe), GitHub events (push, PR), order status updates.

Mental Model

• Short Polling → the "Are we there yet?" kid
• Long Polling → waiting silently at the kitchen
• WebSocket → a phone call that’s always on
• SSE → a TV screen showing updates
• Webhook → the kitchen calls YOU

Quick Comparison