// INSIGHTS
Live Polling and Q&A That Survives a Full Hall
6 min read
Live polling looks trivial until twelve hundred people vote inside the same eleven seconds. Then it is a write-throughput problem, a moderation problem and a stage-management problem at once. The failure is rarely the poll itself. It is the Q&A queue filling with forty versions of the same question, a moderator with no way to merge them, and a speaker reading out something that was answered in the previous slide.
Polling is a write problem, Q&A is a curation problem
Votes arrive in a burst. When an MC says the poll is open, roughly eighty percent of the responses land within the first eleven seconds and then the curve flattens completely. That burst has to be absorbed by writes that are idempotent and enforced server-side. One vote per delegate per poll cannot be a client-side check, because the client will be retried by a flaky connection and by delegates tapping the button repeatedly when nothing appears to happen.
Transport is the second decision. Websockets give the cleanest live experience and they are also the first thing to break on congested venue Wi-Fi, where long-lived connections get dropped by the access point under load. A hybrid works better: websocket where the connection is stable, automatic fallback to short-interval polling where it is not, and a visible state in the interface so the delegate knows whether their vote registered. Silent failure is what makes an audience stop participating for the rest of the day.
Q&A is a different shape of problem. Volume is not the issue; ranking is. A forty-five minute session in a full hall will generate a few hundred questions, most of which are variations on three themes. The moderator needs upvoting to surface demand, a merge action to collapse duplicates, and a three-state queue of pending, approved and dismissed. In India and the UAE the input will also be multilingual, with questions typed in Devanagari, Arabic script, or romanised Hinglish. The moderator console has to render all of it without breaking the layout.
Load profile of a single poll
The parts that keep it standing
Idempotent vote writes
Every vote carries a client-generated key so retries collapse into a single record. Without it, one delegate on a bad connection can add nine votes to a result.
Automatic transport fallback
The client drops from websocket to interval polling when the socket cannot hold, and tells the delegate which mode it is in. Degraded is better than frozen.
A moderator console on a second screen
Separate from the audience app and separate from the stage display, with merge, approve and dismiss on keyboard shortcuts. Moderators work fast or they fall behind.
Distinct speaker and audience views
The speaker sees the approved queue and the next question. The audience sees results only after the vote closes. Mixing the two is how a poll gets herded.
Running a poll from the stage
Pre-load the questions
Load every poll for the session before the speaker walks on, in the running order. Typing a poll question live in front of a full hall never goes well.
Open on a cue
The MC or the speaker opens the poll deliberately, with a countdown on screen. Polls that drift open in the background collect fifteen votes and look broken.
Hold results until close
Keep the live tally off the audience screen while voting is open. Visible running totals pull undecided voters towards whichever option is already ahead.
Publish, then archive
Push the closed result to the stage display, then archive it against the session so it appears in the post-event report. Results that only existed on screen are results that nobody can use on Monday.
What usually goes wrong
The most common self-inflicted problem is showing live results while voting is open. It feels energetic and it corrupts the data, because a visible lead pulls the undecided towards it. The second is having no plan for a network failure. Be honest about this one: if the venue Wi-Fi is fully down, live polling cannot work, and no amount of offline caching changes that. Brief the MC on a fallback before the event, whether that is a show of hands or simply moving on, so the room does not watch a moderator refresh a dead screen for two minutes.
The third is understaffing moderation. One moderator per hall is the floor, and at a few hundred questions in a session that person is fully occupied merging duplicates. Without merge tooling they will simply approve the first ten questions they read, which is not curation. The last decision to make deliberately is anonymity. Anonymous questions get you the honest ones and also the abusive ones, so they need a moderator in front of every item. Named questions suppress the difficult questions but largely police themselves. Pick per session rather than once for the whole event, because a closed-door leadership panel and an open technical track do not have the same needs.
Common questions
Should Q&A be anonymous?
It depends on the session. Anonymity raises question volume and candour, and it requires active moderation because a small number of submissions will be abusive. For panels where delegates are asking about their own organisation's decisions, anonymity is usually worth the moderation cost. For technical tracks, named questions work fine and often lead to better follow-up conversations.
What happens if the venue Wi-Fi fails mid-poll?
Votes already cast are safe on the server, and the client will retry queued votes when connectivity returns. New votes cannot be collected while the network is down, and we do not pretend otherwise. The practical mitigation is a briefed fallback for the MC plus a wired connection for the moderator and stage machines, so at minimum the people running the room stay online.
Can delegates ask questions in Hindi or Arabic?
Yes. Input, storage and the moderator console handle Devanagari, Arabic script with right-to-left rendering, and romanised mixed-script text. Whether the speaker can answer in that language is a programme decision, so most organisers pair multilingual input with a moderator who can translate the approved questions before they go on screen.
Polling that holds in a full hall
Tell us your hall sizes and session format and we will size the load profile with you.
