Imagine you're chatting with a friend on WhatsApp.You send a message.
Within milliseconds, it appears on their screen.
No refresh button No page reload No waiting
It just happens.
But have you ever wondered:
How does WhatsApp know exactly when to deliver that message?
How does Instagram instantly notify you about a new follower?
How does Google Docs show someone else's typing cursor in real time?
How does Uber update your driver's location every few seconds?
The answer lies in a collection of communication patterns and architectures that power modern realtime systems.
(inshort it all depend on what architecture they use for relative system)
In this article, we'll explore:
- Polling
- Long Polling
- Server-Sent Events (SSE)
- WebSockets
- Publish-Subscribe (Pub/Sub)
We'll understand how they work, where they shine, their tradeoffs, and how large-scale applications combine them to build highly responsive experiences.
What Makes a System "Realtime"?
A realtime system is one where information is delivered as soon as a change occurs.
(inshort Realtime is the ability to react to anything that occurs as it occurs, before it loses its importance.)
The goal is to minimize the delay between:
An event happening → The user seeing the update
Examples:
- Chat messages
- Social media notifications
- Live sports scores
- Ride tracking
- Stock market dashboards
- Collaborative editors
Realtime vs Near Realtime
Realtime
Updates are delivered almost immediately.
Example:
- WhatsApp messages
- Online gaming
- Google Docs collaboration
Delay:
- Milliseconds to a few seconds
Near Realtime
Updates arrive shortly after they happen.
Example:
- Analytics dashboards
- Email inbox refresh
- Reporting systems
Delay:
- Several seconds or minutes
Not every system requires strict realtime communication.
Choosing the correct approach depends on business requirements.
Traditional Request-Response Communication
Before understanding realtime communication, let's understand how most web applications work.
Normal HTTP Flow
Example:
- User opens a webpage.
- Browser sends request.
- Server returns data.
- Connection closes.
The server only responds when the client asks.
This model works great for:
- Login systems
- Forms
- E-commerce websites
- CRUD applications
But it struggles with realtime updates.
The Realtime Problem
Suppose a user is waiting for a new message.
How does the browser know a new message arrived?
The server cannot suddenly push information because the connection has already been closed.
The browser has two choices:
- Keep asking repeatedly
- Keep a connection open
The evolution of realtime systems is essentially the story of solving this problem~ shivam yadav.
Polling
Polling is the simplest solution.
How Polling Works
The client repeatedly asks the server:
"Anything new?"
Every few seconds.
Example
A notification system checks every 5 seconds.
setInterval(() => {
fetch('/notifications')
}, 5000)
Advantages
Simple
Easy to understand and implement.
Works Everywhere
Uses standard HTTP requests.
No Special Infrastructure
Can run on almost any backend.
Disadvantages
Wasteful
Most requests return:
"No updates."
Yet resources were consumed.
Delayed Updates
If polling every 10 seconds:
A message may wait 10 seconds before being seen.
High Server Load
100,000 users polling every few seconds creates enormous traffic.
When Polling Is Enough
Polling is often sufficient for:
- Admin dashboards
- Analytics pages
- Low-frequency notifications
- Internal tools
If updates are rare, polling may be the simplest and most practical solution.
Long Polling
Polling wastes requests.
Engineers looked for a better solution.
This led to Long Polling.
How Long Polling Works
Instead of immediately replying:
"No updates"
The server waits.
The client immediately opens another request.
Client ---> Server
Server waits
Server ---> Client
Client ---> Server
Server waits
Long Polling Flow
Benefits
Fewer Unnecessary Requests
Requests stay open longer.
Faster Than Polling
Updates arrive immediately after an event occurs.
Works Over HTTP
No special protocol required.
Drawbacks
Many Open Connections
Each waiting request consumes resources.
More Complex
Timeouts and reconnections must be handled.
Doesn't Scale Easily
Large numbers of users can create server pressure.
Real-World Uses
Historically used by:
- Early chat systems
- Notification systems
- Messaging applications before WebSockets became popular
Server-Sent Events (SSE)
Long Polling improved things.
But browsers still kept reopening requests.
SSE introduced a better model.
What is SSE?
Server-Sent Events allow a server to continuously push updates to the browser through a single HTTP connection.
The client opens one connection.
The server streams updates whenever they occur.
SSE Architecture
One request.
Many updates.
Communication Model
SSE is:
Server → Client
Only.
The client cannot send messages over the same stream.
Advantages
Lightweight
Uses plain HTTP.
Automatic Reconnection
Browsers reconnect automatically.
Easy to Implement
Simpler than WebSockets.
Efficient for Updates
Excellent when information flows mostly one direction.
Limitations
One-Way Communication
Client cannot send realtime data back.
Browser Connection Limits
Can become restrictive with many tabs.
Not Ideal for Interactive Systems
Chat applications need two-way communication.
Perfect Use Cases
- Notifications
- Live dashboards
- Monitoring systems
- News feeds
- Build logs
- AI streaming responses
For example:
When ChatGPT streams tokens while generating a response, SSE is often a great choice.
WebSockets
At this point we still have a limitation.
Clients need to send information too.
Chat applications require:
- Sending messages
- Receiving messages
Simultaneously.
This is where WebSockets shine.
What Are WebSockets?
WebSockets create a persistent connection between client and server.
and when i say persistent i mean to say continues
Instead of repeatedly opening connections:
One connection stays alive.
Connection Lifecycle
Client <===============> Server
Data flows both ways.
Bidirectional Communication
Client ---- Message ----> Server
Client <--- Message ----- Server
Client ---- Message ----> Server
Client <--- Message ----- Server
No repeated requests.
No repeated handshakes.
Why Chat Applications Use WebSockets
Consider WhatsApp.
User A sends a message.
User A --> Server --> User B
The server instantly pushes the message.
No refresh.
No polling.
No waiting.
This requires bidirectional communication.
Benefits
Low Latency
Messages arrive almost instantly.
Efficient
Connection established once.
Full Duplex
Both sides communicate anytime.
Ideal for Realtime Apps
Perfect for highly interactive experiences.
Limitations
Connection Management
Servers must track active connections.
Scaling Complexity
Millions of open connections require specialized infrastructure.
Load Balancing Challenges
Connection state must be managed carefully.
Common Use Cases
- Chat applications
- Multiplayer games
- Collaborative editing
- Live trading systems
- Ride tracking
Pub/Sub Systems
Polling, SSE, and WebSockets describe communication methods.
Pub/Sub is different.
Pub/Sub is an architectural pattern.
What is Publish-Subscribe?
Instead of services directly talking to each other:
They communicate through topics.
Core Components
Publisher
Produces events.
Topic
Channel where events are sent.
Subscriber
Receives events.
Architecture
Publishers don't know subscribers.
Subscribers don't know publishers.
Everything is decoupled.
Example: Notification System
User receives a message.
Message Service
|
v
"new-message"
|
v
Notification Service
Mobile Push Service
Analytics Service
One event.
Multiple consumers.
Benefits
Loose Coupling
Services remain independent.
Scalability
Consumers can grow independently.
Reliability
Messages can be retried.
Event Driven
Perfect for modern distributed systems.
Real Examples
Popular Pub/Sub systems include:
- Apache Kafka
- Redis Pub/Sub
- RabbitMQ
- Google Pub/Sub
- AWS SNS/SQS
Comparing All Approaches
Polling vs Long Polling
| Feature | Polling | Long Polling |
|---|---|---|
| Requests | Frequent | Fewer |
| Latency | Higher | Lower |
| Complexity | Simple | Moderate |
| Resource Usage | Wasteful | Better |
Long Polling vs SSE
| Feature | Long Polling | SSE |
|---|---|---|
| Connection | Reopened repeatedly | Persistent |
| Server Push | Limited | Excellent |
| Complexity | Higher | Lower |
SSE vs WebSockets
| Feature | SSE | WebSockets |
|---|---|---|
| Direction | One-way | Two-way |
| Complexity | Simpler | More Complex |
| Notifications | Excellent | Excellent |
| Chat Apps | Poor | Excellent |
WebSockets vs Pub/Sub
| Feature | WebSockets | Pub/Sub |
|---|---|---|
| Protocol | Yes | No |
| Client Communication | Yes | Usually No |
| Architecture Pattern | No | Yes |
| Service Coordination | Limited | Excellent |
Building Realtime Systems at Scale
Building a realtime system for 100 users is easy.
Building one for millions is hard.
Handling Thousands of Connections
Every WebSocket connection consumes:
- Memory
- CPU
- Network resources
Large systems distribute users across multiple servers.
Horizontal Scaling
Instead of:
1 Server
We use:
Load Balancer
/ | \
S1 S2 S3
Traffic spreads across machines.
The Connection State Problem
Suppose:
User A is connected to Server 1.
User B is connected to Server 3.
How does Server 1 know where User B lives?
A shared messaging layer becomes necessary.
Pub/Sub Enables Scaling
Server 1
\
\
Kafka
/
/
Server 2
Server 3
A message published by one server becomes visible to all others.
This is how large chat systems coordinate delivery.
Reliability Considerations
Large-scale systems must address:
- Message ordering
- Duplicate messages
- Failed deliveries
- Reconnection handling
- Offline users
- Data persistence
Realtime communication is not only about speed.
It's also about correctness.
Choosing the Right Approach
There is no universal winner.
The correct solution depends on requirements.
Chat Applications
Recommended:
- WebSockets
- Pub/Sub for scaling
Examples:
- Discord
- Slack
Notification Systems
Recommended:
- SSE
- Polling for simpler systems
Examples:
- GitHub notifications
- Social media alerts
Live Sports Scores
Recommended:
- SSE
- WebSockets
Updates are frequent but mostly one-way.
Stock Market Dashboards
Recommended:
- WebSockets
Need low latency and high update frequency.
Collaborative Applications
Recommended:
- WebSockets
- Pub/Sub
Examples:
- Google Docs
- Figma
IoT Systems
Recommended:
- WebSockets
- Pub/Sub
Thousands of devices continuously exchange events.
And this is the end
The evolution of realtime communication follows a natural progression:
Polling → Long Polling → SSE → WebSockets
As systems grow, another layer appears:
Pub/Sub
Each solution exists because it solves a specific problem.
- Polling is simple.
- Long Polling reduces waste.
- SSE enables efficient server-to-client streaming.
- WebSockets enable true bidirectional communication.
- Pub/Sub enables systems to scale across many services and servers.
The next time a WhatsApp message arrives instantly, a stock price updates live, or a Google Docs cursor moves across your screen, you'll know the engineering patterns making that experience possible.
The best realtime architecture is not the most advanced one.
it's what suites your business
if u like the blog then comment a heart and meet u in the next blog bye
