WebSockets vs Polling

When building a real-time system—like sending an incoming order straight to a busy kitchen display—you have two main choices: HTTP Polling or WebSockets.

Initially, polling seems like the easiest path. The kitchen app just asks the server, "Any new orders?" every 3 seconds. But at scale, this turns into a performance disaster. If you have 500 restaurants online, that's 10,000 requests per minute slamming your database just to find out absolutely nothing has happened.

By moving to a WebSockets approach paired with Redis, we completely flipped the model. Instead of the clients repeatedly asking for data, the server holds a lightweight, persistent connection and pushes the data the exact millisecond an order arrives.

          [ Old Way: Polling ]                  [ New Way: WebSockets + Redis ]
                                                  
 [ App ] ---? (Any orders?) ---> [ DB ]       [ App ] <---(Push)--- [ WebSocket ]
 [ App ] <--- (No) ------------- [ DB ]                                   ^
 [ App ] ---? (Any orders?) ---> [ DB ]                                   | (Subscribes)
 [ App ] <--- (No) ------------- [ DB ]                                   |
 [ App ] ---? (Any orders?) ---> [ DB ]       [ API ] ---(Publishes)--> [ Redis ]

Here's how it flows: When a customer places an order via the API, the API writes it to the database just once, and immediately publishes an event to Redis. Our Node.js WebSocket server—which is subscribed to Redis—receives that event and pushes it only to the specific restaurant's connected device.

The result? We saw an 80-90% reduction in database I/O, and we could comfortably handle 5x more concurrent users on the exact same server hardware, all while achieving sub-50ms latency for order delivery.