Overview
What It Is
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
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.
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.
Key Points
- client controls communication
- server responds immediately
- requests happen repeatedly
- many responses may contain no useful data
- simple to understand and implement
Problems
Short polling can create many unnecessary requests.
This can cause:
- wasted bandwidth
- extra server load
- poor scalability
- inefficient real-time behavior
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.
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
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.
Key Points
- fewer unnecessary requests than short polling
- server responds only when data is ready
- after response, client reconnects
- still follows request-response style
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
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.
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.
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
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
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.
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.
Key Points
- server sends updates to client
- one-way communication only
- uses standard HTTP
- simpler than WebSocket
- automatically reconnects if the connection drops
Advantages
SSE is lightweight and simple for server-to-client updates.
Good for:
- streaming updates
- live feeds
- dashboards
- simple real-time notifications
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
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.
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.
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
Advantages
Webhooks are very efficient because they avoid unnecessary calls.
Benefits:
- no polling
- real-time event notification
- scales well
- works without maintaining persistent connection
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
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 |
Basic Checklist
Use short polling only when real-time is not critical
Use long polling when server should wait for data before responding
Use WebSocket when both client and server need to send messages anytime
Use SSE when only the server needs to stream updates to the client
Use webhooks when one backend system must notify another system
Avoid polling when an event-driven approach is enough
Choose based on direction, connection type, efficiency, and real-time need
Interview Style Answer
Communication techniques define how data moves between clients, servers, and backend systems. Short polling sends repeated requests at fixed intervals, which is simple but inefficient. Long polling keeps a request open until data is available, reducing unnecessary responses but still using a request-response cycle. WebSocket keeps a persistent two-way connection open, making it best for real-time interactive systems like chat, trading, games, and notifications. SSE keeps a one-way server-to-client stream open using HTTP, making it useful for dashboards, news feeds, and stock updates. Webhooks are server-to-server event notifications where one system calls another system only when something happens, such as payment success, GitHub events, or order status updates.
One-Line Summary
Communication Overview = Choose Short Polling, Long Polling, WebSocket, SSE, or Webhooks based on update direction, real-time need, and efficiency.
Final Mental Model
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