Back to Basics: Why We Chose Long Polling Over WebSockets

submited by

Style Pass

2025-01-05 07:30:05

Learn how we implemented real-time updates using Node.js, TypeScript, and PostgreSQL with HTTP long polling. A practical guide to building scalable real-time systems without WebSockets.

Like many teams building real-time systems with Node.js and TypeScript, we've been exploring ways to handle real-time updates at scale. Our system handles hundreds of worker nodes constantly polling our PostgreSQL-backed control plane for new jobs (tool calls issued by agents), while agents themselves continuously pull for execution and chat state updates. What started as an exploration into WebSockets led us to a surprisingly effective "old-school" solution: HTTP long polling with Postgres.

Short polling is like a train that departs strictly according to a timetable - it leaves the station at fixed intervals regardless of whether there are passengers or not. WebSockets, on the other hand, are like having a dedicated train line always ready to transport passengers.

Long polling? It's like a train that waits at the station until at least one passenger boards before departing. If no passengers show up within a certain time (TTL), only then does it leave empty. This approach gives you the best of both worlds - immediate departure when there's data (passengers) and efficient resource usage when there's not.