A timer and a fetch
Short polling is a timer and a fetch. Your client asks for updates every few seconds, your server answers right away with whatever it has, and the loop runs forever.
In a browser that is one line setting an interval, and nothing else. No special server, no held connections, no new protocol. Every request is ordinary HTTP that any balancer, proxy or serverless platform already understands.
Accept the property that defines it: your freshness can never beat your interval. Poll every 5 seconds and an update landing just after a poll waits nearly 5 seconds to be seen. On average your users are half an interval behind, and at worst a full one plus the network.
Reach for something else if your product needs sub-second delivery, because no interval short enough will leave your servers standing.
Making it decent
Make the empty case cheap. That is the first thing separating decent polling from embarrassing polling. Send a cursor or a validation header so your server can answer nothing new off a single index lookup instead of assembling a full payload.
Add jitter second. If every client polls on the minute because they all started together, you get a synchronised spike every 60 seconds and silence in between. A random offset flattens it.
Back off when nothing changes, a habit worth stealing from production pollers. Double the interval after a few empty answers and snap back to fast as soon as something arrives.
Picture a payment status page doing exactly that: every 2 seconds for the first 30, when the answer usually comes, then relaxing to every 10. Your client controls the rhythm, and that is both the entire appeal and the entire limitation of this technique.
Worked example
Noor ships an order tracking page for a food delivery startup. Version one polls GET /orders/812/status every 10 seconds, and testers complain the courier icon jumps whole blocks at a time. She drops the interval to 2 seconds, the map smooths out, and the backend team notices request volume for the endpoint went from 900 to 4,500 per second at dinner peak. The compromise ships a week later: poll every 2 seconds while the order is out for delivery, every 15 seconds otherwise, with the status check served from Redis instead of Postgres. Peak load lands at 1,800 requests per second, the courier icon stays smooth for the 12 minutes customers actually watch it, and nobody has to run any new infrastructure.