Communication Overview

Communication techniques define how the client, server, or different backend systems exchange data.

Different techniques are used depending on how fast the update is needed, who starts the communication, and whether the connection should stay open.

Communication Technique = How data moves between client, server, and systems

One-line idea: Communication Overview = Choose Short Polling, Long Polling, WebSocket, SSE, or Webhooks based on update direction, real-time need, and efficiency.

Core Concepts

Why It Matters

Not every application needs the same communication style.

Some apps only need occasional updates.

Some apps need near real-time data.

Some apps need continuous two-way communication.

Some systems only need to notify another system when an event happens.

Choosing the right technique helps improve:

• performance
• scalability
• user experience
• server efficiency
• real-time behavior

Main Communication Techniques

The common communication techniques are:

Technique	Main Idea
Short Polling	Client asks server repeatedly
Long Polling	Client asks once and server waits until data is ready
WebSocket	Client and server keep a two-way connection open
SSE	Server continuously sends updates to the client
Webhooks	One server notifies another server when an event happens

Restaurant Analogy

Think of the frontend as a restaurant customer and the backend as the kitchen.

Frontend / Client -> Customer
Backend / Server  -> Kitchen

Each communication technique is like a different way of checking whether the food is ready.

Short Polling

Short polling means the client sends requests to the server at fixed intervals.

Example:

Every 2-5 seconds:
Client asks server -> Any new data?

The server responds immediately every time, even if there is no new data.

Short Polling: Restaurant Analogy

You keep walking to the kitchen again and again:

Is my order ready now?
Now?
Now?

Most of the time, the kitchen says:

Not ready yet.

Short Polling: Key Points

• client controls communication
• server responds immediately
• requests happen repeatedly
• many responses may contain no useful data
• simple to understand and implement

Short Polling: Problems

Short polling can create many unnecessary requests.

This can cause:

• wasted bandwidth
• extra server load
• poor scalability
• inefficient real-time behavior

Short Polling: When to Use

Short polling is useful for simple apps where real-time updates are not critical.

Example:

Checking status every few seconds in a small internal tool.

Practical Examples

Long Polling

Long polling means the client sends a request, but the server keeps the connection open until data is available.

After the server responds, the client sends another request again.

Client asks once -> Server waits -> Server responds when data is ready -> Client asks again

Long Polling: Restaurant Analogy

You go to the kitchen once and stand there silently until your food is ready.

The kitchen does not respond again and again.

It only responds when the order is ready.

Long Polling: Key Points

• fewer unnecessary requests than short polling
• server responds only when data is ready
• after response, client reconnects
• still follows request-response style

Long Polling: Problems

Long polling is better than short polling, but it still has limitations.

Problems include:

• connection stays open
• server resources are used while waiting
• not true real-time like WebSocket
• small delay may happen between reconnects

Long Polling: When to Use

Long polling was commonly used in older real-time apps before WebSockets became popular.

Example:

Waiting for updates where WebSocket is not available.

WebSocket

WebSocket creates a persistent, full-duplex connection between client and server.

Full-duplex means both sides can send messages anytime.

Client <-> Server

The connection stays open, so repeated HTTP requests are not needed.

WebSocket: Restaurant Analogy

You and the kitchen have a direct walkie-talkie connection.

You: Any update?
Kitchen: Cooking done in 2 mins.
Kitchen: Order ready!

The kitchen can also send updates without you asking again.

WebSocket: Key Points

• one connection stays open
• client can send messages anytime
• server can send messages anytime
• supports true real-time communication
• low latency
• efficient for live updates

WebSocket: Advantages

WebSocket is useful when the application needs fast two-way communication.

Benefits:

• very fast updates
• no repeated HTTP requests
• efficient for frequent messages
• best for interactive real-time systems

WebSocket: Use Cases

Common WebSocket use cases:

• chat apps
• live trading apps
• multiplayer games
• notification systems

SSE

SSE stands for Server-Sent Events.

SSE allows the server to continuously send updates to the client over a single connection.

It is one-way communication.

Server -> Client

The client receives updates, but does not send messages back over the same connection.

SSE: Restaurant Analogy

The kitchen installs a live display board.

Order #21 cooking
Order #21 ready

You just sit and watch the display.

You do not need to keep asking the kitchen.

SSE: Key Points

• server sends updates to client
• one-way communication only
• uses standard HTTP
• simpler than WebSocket
• automatically reconnects if the connection drops

SSE: Advantages

SSE is lightweight and simple for server-to-client updates.

Good for:

• streaming updates
• live feeds
• dashboards
• simple real-time notifications

SSE: Limitations

SSE is not suitable when the client also needs to send frequent messages to the server over the same connection.

Limitations:

• no client-to-server communication through the same stream
• not ideal for interactive two-way apps

SSE: Use Cases

Common SSE use cases:

• live dashboards
• news feeds
• stock price updates

Webhooks

Webhooks are used for server-to-server communication.

A server sends data automatically to another system when an event happens.

Event happens -> Server sends data to configured URL

No polling is needed.

Webhooks: Restaurant Analogy

Instead of waiting or asking again and again, you give your phone number to the kitchen.

The kitchen calls you:

Your order is ready, come pick it up.

Webhooks: Key Points

• event-driven communication
• no repeated requests from client
• triggered only when something happens
• does not require an open connection
• usually server-to-server

Webhooks: Advantages

Webhooks are very efficient because they avoid unnecessary calls.

Benefits:

• no polling
• real-time event notification
• scales well
• works without maintaining persistent connection

Webhooks: Limitations

Webhooks require proper setup.

Limitations:

• needs URL endpoint
• needs security handling
• depends on external system availability
• receiver must be ready to accept the event

Webhooks: Use Cases

Common webhook use cases:

• payment success notifications
• Razorpay events
• Stripe events
• GitHub push events
• GitHub pull request events
• order status updates

Quick Comparison

Feature	Short Polling	Long Polling	WebSocket	SSE	Webhooks
Connection	Repeated	Held	Persistent	Persistent	None
Direction	Client -> Server	Client -> Server	Both	Server -> Client	Server -> Server
Real-time	No	Almost	Yes	Yes	Yes
Efficiency	Low	Medium	High	High	Best
Best For	Simple status checks	Older real-time apps	Interactive real-time apps	Server update streams	Event-driven system updates

Choosing the Right Technique

Need	Best Technique
Simple periodic checking	Short Polling
Reduce repeated empty responses	Long Polling
Two-way real-time communication	WebSocket
One-way live server updates	SSE
Server-to-server event notification	Webhooks

Summary

Communication Overview = Choose Short Polling, Long Polling, WebSocket, SSE, or Webhooks based on update direction, real-time need, and efficiency.

Short Polling -> Are we there yet?
Long Polling -> Wait silently until ready
WebSocket -> Phone call always on
SSE -> Live display board
Webhook -> Kitchen calls you