Real-Time Voting and Polls for Your Website

Imagine: a conference with 10,000 participants, organizers launch a vote, and results update every 30 seconds via regular AJAX polling. Users complain about delays, the server crashes under 10,000 requests per second. Sound familiar? Choosing real-time voting solves two problems: instant result delivery and reduced server load. We have implemented such systems for 30+ projects — from corporate surveys to large-scale live streams.

Why SSE Instead of Polling?

Polling means N requests per second, where N is the number of users. With 500 users — 500 req/s wasted. SSE or WebSocket give one connection per user, through which the server sends data only when it changes. For voting, two mechanisms work: SSE (Server-Sent Events) and WebSocket. A third option — polling — we do not consider: 1 request per second for 500 concurrent users is 500 req/s load just to check "nothing changed." SSE is a unidirectional stream from server to client, described in the EventSource specification. For polls this is sufficient: the vote is sent via ordinary POST, the result arrives via SSE. WebSocket is justified if you need immediate feedback (animation "your vote accepted") or additional interactive elements.

How to Prevent Duplicate Voting?

For authorized users — unique constraint (option_id, user_id) and check in controller. For anonymous voting — protection via IP + fingerprint. Fingerprint is generated on the frontend (library fingerprintjs) and passed in the header. This is not absolute protection but sufficient for most cases.

$fingerprint = $request->header('X-Client-Fingerprint'); $alreadyVoted = PollVote::where('poll_id', $poll->id) ->where(function ($q) use ($request, $fingerprint) { $q->where('ip', $request->ip()) ->orWhere('fingerprint', $fingerprint); })->exists(); 

Additionally, you can use Redis locks: Cache::lock('vote:'.$poll->id.':'.$userId, 10)->get() — this prevents simultaneous submission from one account.

How to Scale Voting to Thousands of Participants?

A PHP application with SSE keeps the connection open. 1,000 concurrent users = 1,000 PHP workers. This is expensive. Solution: offload broadcasting via Pusher or Laravel Echo Server (socket.io). Then the SSE controller is no longer needed — the client subscribes to a channel, the server publishes a poll.updated event to Redis, Laravel Echo broadcasts to all subscribers.

// After recording a vote broadcast(new PollUpdated($poll->id, $counts))->toOthers(); 

Echo.channel(`poll.${pollId}`) .listen('PollUpdated', ({ counts }) => updateBars(counts)); 

This architecture handles hundreds of thousands of connections on a single Node.js process. For monitoring, use Laravel Horizon: it shows the number of active SSE workers and response time. This saves up to 70% on server infrastructure costs compared to direct SSE workers.

Data Schema and Optimization

CREATE TABLE polls ( id BIGSERIAL PRIMARY KEY, title VARCHAR(500) NOT NULL, is_multiple BOOLEAN NOT NULL DEFAULT false, is_active BOOLEAN NOT NULL DEFAULT true, ends_at TIMESTAMP, created_at TIMESTAMP NOT NULL DEFAULT NOW() ); CREATE TABLE poll_options ( id BIGSERIAL PRIMARY KEY, poll_id BIGINT NOT NULL REFERENCES polls(id) ON DELETE CASCADE, label VARCHAR(255) NOT NULL, position SMALLINT NOT NULL DEFAULT 0 ); CREATE TABLE poll_votes ( id BIGSERIAL PRIMARY KEY, option_id BIGINT NOT NULL REFERENCES poll_options(id), user_id BIGINT REFERENCES users(id), ip INET, voted_at TIMESTAMP NOT NULL DEFAULT NOW(), UNIQUE(option_id, user_id) ); 

Aggregation is computed via a materialized view or direct COUNT. Under peak load (live stream, 5,000+ participants), it is better to store counters separately and increment via Redis: HINCRBY poll:42:counts 1 1.

Client-Side and Sending Votes

const pollId = 42; const source = new EventSource(`/api/polls/${pollId}/stream`); source.onmessage = (event) => { const { counts } = JSON.parse(event.data); updateBars(counts); }; source.onerror = () => { console.warn('SSE reconnecting...'); }; function updateBars(counts) { const total = Object.values(counts).reduce((a, b) => a + Number(b), 0); document.querySelectorAll('[data-option-id]').forEach(el => { const id = el.dataset.optionId; const pct = total > 0 ? Math.round((counts[id] || 0) / total * 100) : 0; el.querySelector('.bar').style.width = pct + '%'; el.querySelector('.label').textContent = pct + '%'; }); } async function vote(optionId) { const resp = await fetch(`/api/polls/${pollId}/vote`, { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-CSRF-Token': csrfToken }, body: JSON.stringify({ option_id: optionId }), }); if (resp.status === 409) { showMessage('You have already voted'); } } 

Implementing an SSE Endpoint in Laravel

Route::get('/api/polls/{poll}/stream', function (Poll $poll) { return response()->stream(function () use ($poll) { while (true) { if (connection_aborted()) break; $counts = PollVote::selectRaw('option_id, COUNT(*) as votes') ->whereIn('option_id', $poll->options->pluck('id')) ->groupBy('option_id') ->pluck('votes', 'option_id'); $data = json_encode(['counts' => $counts, 'ts' => now()->timestamp]); echo "data: {$data}\n\n"; ob_flush(); flush(); sleep(2); } }, 200, [ 'Content-Type' => 'text/event-stream', 'Cache-Control' => 'no-cache', 'X-Accel-Buffering' => 'no', ]); }); 

X-Accel-Buffering: no is a mandatory header when using Nginx as a proxy; otherwise data will accumulate in the buffer.

How to Test Real-Time Voting?

Use tools: Postman for sending votes, k6 for load testing, browser console for checking SSE connections. Main scenarios: 1) check receiving updates after voting; 2) simulate simultaneous votes from a thousand users; 3) check resilience on connection drop (SSE auto-reconnects).

Common Mistakes and Solutions

• N+1 queries: when retrieving the list of votes with lazy-loaded options. Use with('options') in Eloquent.
• Missing X-Accel-Buffering: without this header, Nginx buffers the SSE stream, and users see data in chunks.
• Ignoring connection_aborted(): without it, PHP workers continue hanging, consuming memory.
• Not using Redis for counters: direct COUNT from DB on each update creates load. Redis increments are much faster.

Development Timelines

We guarantee a bug-free period of 30 days after delivery, provide documentation, and train your team. To evaluate your project, contact us — get a detailed plan and precise timeline. Request a consultation to ensure your voting runs smoothly under any load.