Imagine you're building a SaaS platform.
Nothing fancy.
Just a notification bell in the top-right corner.
When someone receives a new message, completes a task, or gets assigned work, the bell should update.
Seems simple, right?
A developer might propose:
Every 5 seconds:
GET /notifications
Done.
Feature shipped.
Customers happy.
Everyone goes home.
For a while.
The Architecture Looks Innocent
With 10 users online, the system behaves exactly as expected.
10 Users
↓
GET /notifications
Every 5 seconds
Nobody notices a problem.
The database barely feels the load.
The servers are mostly idle.
The feature appears successful.
This is where many architectural mistakes begin.
Not because the solution is wrong.
But because it works.
Success Changes the Equation
Six months later, your product gains traction.
Now you have:
5,000 active users
The code hasn't changed.
The infrastructure hasn't changed.
The polling interval is still:
Every 5 seconds
But the system is now processing:
5,000 × 12 requests/minute
= 60,000 requests per minute
That's:
3.6 million requests per hour
For a notification system.
Not file uploads.
Not payments.
Not business-critical operations.
Just checking whether something changed.
The Hidden Question
Here's the question experienced engineers ask:
How many of those requests actually matter?
Let's assume only 5% of users receive a notification during a given minute.
That means 95% of requests exist only to discover:
{
"notifications": []
}
The system is spending CPU, memory, network bandwidth, and database resources simply confirming that nothing happened.
From a business perspective, that's interesting.
Because the company isn't paying for useful work.
It's paying for uncertainty.
Why Companies Still Choose Polling
At this point, many articles declare:
"Polling is bad."
That's the wrong conclusion.
Companies don't buy architectures.
Companies buy outcomes.
Polling remains popular because it optimizes for something businesses care deeply about:
Speed of Delivery
A startup founder rarely asks:
"Is this the most elegant distributed systems solution?"
They ask:
"Can we launch this feature next week?"
Polling is attractive because:
Easy to implement
Easy to debug
Easy to maintain
Works through almost every network and firewall
Requires minimal infrastructure
In other words:
Higher operational cost
↓
Lower development cost
And early-stage companies often prefer that tradeoff.
The Real Architectural Tradeoff
Junior developers often think:
Polling vs WebSockets
Senior engineers think:
Development Cost
vs
Infrastructure Cost
vs
User Experience
vs
Future Scale
Those are completely different conversations.
Every architecture decision is a business decision wearing a technical disguise.
When Polling Becomes Expensive
Imagine your SaaS platform grows to:
100,000 active users
Still polling every 5 seconds.
Now the system receives:
20,000 requests every second
Suddenly:
More application servers
Larger database clusters
Higher cloud bills
More monitoring
More operational complexity
The notification feature itself hasn't become more valuable.
The architecture simply became more expensive.
This is one of the easiest ways successful products accidentally create technical debt.
Not through bad code.
Through successful growth.
The Most Important Lesson
Polling is not a communication pattern.
Polling is an optimization choice.
You're optimizing for:
Simplicity Today
while accepting:
Higher Costs Tomorrow
Sometimes that's exactly the right decision.
Sometimes it's not.
The best engineers aren't the ones who know the newest technologies.
They're the ones who understand the tradeoffs.
And Polling is one of the simplest examples of that principle.
Top comments (0)