One input decides the load
The load arithmetic here has one input that matters. Requests per second is your number of clients divided by your poll interval.
Ten thousand clients on a 5 second interval is 2,000 requests a second, around the clock, whether anything changed or not.
Notice which way that scales. Your load tracks how many people are watching, never how much is happening, and that is backwards from what you want. A quiet Tuesday costs you exactly what a breaking-news Saturday costs.
Count what each of those requests actually spends. It crosses your balancer, runs your framework's middleware, validates a session, and usually runs at least one query. If 99 percent of your polls return nothing, 99 percent of that work bought nothing.
Watch the subtler bill on the client. On a phone, each poll can wake the radio out of idle, and a chatty poller is a reliable way to appear in somebody's battery report.
The knobs you have
Count your knobs, because there are few. Stretch the interval and you trade freshness for load in a straight line. Cache the answer, in memory or at a CDN when the feed is shared instead of per-user, and each poll costs less even though the count does not move. Conditional requests cut bytes and still spend a request.
No knob makes polling cost track events, because your client is guessing when events happen.
Run the arithmetic before you choose rather than after. If clients times polls a minute lands in the tens of requests a second, polling is free and you should stop optimising. If it lands in the thousands, you are about to pay for a fleet of servers whose main job is saying nothing yet.
Worked example
An edtech company runs a teacher dashboard that polls five endpoints every 3 seconds to keep its counters live. With 6,000 teachers online during school hours, that is 10,000 requests per second, and their RDS instance sits at 70 percent CPU serving queries whose answers change a few times an hour. Marcus, the newest backend hire, spends an afternoon on arithmetic instead of code: collapsing the five endpoints into one summary endpoint cuts load to 2,000 rps, serving it from a 5 second Redis cache cuts database traffic by 99 percent, and stretching the interval to 10 seconds for unfocused browser tabs halves what remains. Same product behavior, same polling architecture, and the RDS instance drops two sizes at the next reservation renewal.