Polling: When "simple" Starts Sending Millions Of Requests

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.