Reinventing Polling

When GPT shook the world, there was no Enterprise edition yet.

For compliance-minded corporations, this was an uncomfortable place to be. Fear that internal data might be ingested into training sets. Simultaneous pressure from above: "We need to leverage AI too." Both forces arriving at once. Their answer was simple. Hit the GPT API, build an internal GPT clone. Data stays inside. The board gets an explanation that works. The logic held up.

I looked at what they built and saw history looping.

There is a technology called SSE. Server-Sent Events. A mechanism for streaming data one-way from server to client. It rides on top of HTTP, so it is less ceremony than WebSocket. You hold the connection open, the server pushes events as they come. That character-by-character flow in ChatGPT — that is SSE. It only became widely known recently. Many people encountered it for the first time through GPT-style chat services.

Their clone used polling instead.

Hit the API every few seconds. Check if a response has arrived. If yes, display it. If not, wait. Hit again. A company large enough to be classified as enterprise, every employee polling at once. It crashed often. Of course it did. The nightmare of the Ajax-polling era — pseudo-realtime before WebSocket — faithfully reproduced.

SSE needs one connection. It follows the HTTP spec, so proxies and CDNs let it through. Reconnection logic is part of the standard. The EventSource API is a few lines of code. No wasted requests like polling. No protocol upgrade like WebSocket. When the use case fits, it is the cleanest choice available.

Reinventing the wheel is an engineer's nature. You build it yourself, you understand it for the first time. But what I felt in that moment was not empathy. It was deflating. An existing technology, unknown to the builders, the same problem solved again in a degraded form. And nobody stopped it.

History repeats. So does polling.