Why Modern Engineering Teams Overuse WebSockets - And When Polling Is Actually The Better Architectural Decision

Vishal Kumar — Sun, 24 May 2026 14:16:06 +0000

During my time at companies such as Amadeus IT Group — the world’s largest Global Distribution System powering backend infrastructure for around 82% of the world’s scheduled flights — WebSockets were frequently discussed as a solution for bidirectional communication and realtime system synchronization.

Right before I left the company, one engineer told me that a solution I had built solved a problem he had struggled with internally for almost 20 years due to repeated polling patterns.

That conversation stuck with me.

At my current company, I’ve noticed that WebSockets are often treated as the default architectural choice over polling. While real-time infrastructure absolutely has valid use cases, I’ve also seen scenarios where the operational complexity introduced by WebSockets was not actually justified by the business requirement.

In one financial services system I worked on, WebSockets had been implemented despite the fact that real-time synchronisation provided minimal practical value. Polling would likely have achieved the same outcome with significantly simpler infrastructure and operational overhead.

This raises an interesting question:

How often are engineering teams introducing real-time infrastructure simply because it feels like the “modern” architectural choice?

Before going further into that discussion, it’s worth first understanding the difference between polling and WebSockets.

Polling

Polling is a communication pattern where a client repeatedly sends requests to a server at fixed intervals to check whether new data is available.

For example:

every second
every 30 seconds
every few minutes

Each request is stateless and independent, which makes polling architectures relatively straightforward to scale, debug, and operate.

However, the tradeoff is that many of these requests may return no new information at all, resulting in unnecessary network and compute overhead.

WebSockets

WebSockets establish a persistent bidirectional connection between client and server, allowing servers to push updates immediately without requiring repeated client requests.

Unlike polling, the connection remains open continuously, enabling low-latency communication in realtime systems.

This is especially useful in applications such as:

live chat systems
trading platforms
collaborative editing tools
multiplayer games
AI-native streaming interfaces

However, this lower latency comes with additional operational complexity.

When Polling Is Actually The Better Choice
1. When Eventual Consistency Is Acceptable

Not every system requires millisecond-level synchronization.

In many applications, slightly stale data is operationally acceptable as long as updates arrive within a reasonable timeframe.

Examples include:

analytics dashboards
reporting systems
internal admin tooling
background processing workflows

In these scenarios, polling every 15–30 seconds is often more than sufficient.

Maintaining persistent realtime infrastructure for systems like these can introduce unnecessary complexity for minimal practical gain.

2. When Stateless Scaling Matters More

Polling architectures are significantly easier to scale horizontally because each request is independent.

This simplifies:

load balancing
autoscaling
retry handling
failure recovery

Load balancers can distribute requests freely without maintaining long-lived connection state between clients and servers.

In contrast, WebSockets introduce persistent connection management, heartbeat handling, reconnect logic, and stateful infrastructure requirements.

At scale, this operational difference becomes substantial.

3. When Operational Simplicity Is More Valuable Than Low Latency

One of the most overlooked costs of real-time systems is infrastructure complexity.

Polling systems are generally:

easier to debug
easier to observe
easier to deploy
easier to recover during failures

WebSockets, meanwhile, require engineering teams to manage:

persistent connections
reconnect storms
idle connection overhead
state synchronization
gateway scaling challenges

In many systems, the operational burden introduced by realtime infrastructure is simply not justified by the actual user requirement.

Conclusion

Modern engineering increasingly trends toward realtime infrastructure, but lower latency alone does not justify higher architectural complexity.

Polling optimizes for operational simplicity.

WebSockets optimize for low-latency synchronization.

The best systems are not the most technologically advanced — they are the systems whose complexity is justified by the business requirement.

Why AI Engineering Is Becoming More Like Distributed Systems Engineering

Vishal Kumar — Thu, 21 May 2026 20:45:18 +0000

As foundation models continue to improve, I think AI engineering is starting to look far more like distributed systems engineering.

The difficult part usually is not the model itself - it is everything around it:

Orchestration
Retries
Queues
Workflow state
Observability
Evaluation
Scaling

A production AI workflow can very quickly become:

Retrieval
Multiple LLM/tool calls
Async processing
Validation
Downstream systems

At that point, you are dealing with classic system problems rather than just prompting.

Importance of Data Modelling

Vishal Kumar — Sat, 16 May 2026 10:10:40 +0000

As CodeGen tools continue to develop, with tools such as Graphify optimising token usage even further, pressure is mounting on business teams looking to leverage AI-native solutions within their data collection standards.

Thoughts

Model performance tends to rely heavily on the data.
As development time decreases, bottlenecks around data dependencies increase.
This is why data modelling is becoming increasingly crucial for businesses these days.

Let me know your thoughts on this!