Skip to main content
DBB Software logo

Building Real-Time Chat, Polls and Q&A for a Live-Streaming App

DBB Software built the real-time layer of a creator live-streaming app: chat, reactions, polls and Q&A that every viewer saw at the same moment, from build through the app's 2024 launch.

Industry

Media & Entertainment

Service

Web Development

Team

2 Team Leads (FE and BE), BE Developers, Mobile Developers, DevOps Engineers, QA Engineers

Project State

May 2023 - May 2024

Country

nda

NDA

NDA: Social Streaming Platform Case
NDA

About the Client

The client is a startup that built a social live-streaming app for creators, released on iPhone and Android in 2024. Creators broadcast live to their followers from a phone or from studio software. Viewers browse a full-screen feed of live streams, interact with creators during broadcasts and support them through paid subscriptions.

The Client's Initial Request

The client engaged DBB Software to build live interaction into its streaming app because creators and viewers needed to talk to each other while a broadcast was running.

Live Interaction in Every Stream

Chat, reactions, polls and Q&A that every viewer sees at the same moment.

01

Smooth Handling of Spikes

The platform keeping up when a whole audience votes or reacts at once.

02

Late Joiners in Sync

Viewers arriving mid-stream seeing the current poll, Q&A and chat state right away.

03

Creator Control

Creators running polls and Q&A, removing comments and switching chat off.

04

Safe Live Chat

Harmful messages caught without slowing the conversation.

05

The Deliverables

DBB Software built the real-time layer that kept every viewer of a stream in sync.

Shared Real-Time Channel

Each stream had one real-time channel, shared by every server copy.

Socket.IO, a real-time messaging library, ran on uWebSockets.js, a WebSocket server written in C++. The team moved to this setup from the standard Node.js server.

Socket.IO's Redis Streams adapter, which replaced the earlier Redis adapter, linked the server copies, so viewers connected to different servers shared the same room.

Every connection needed a signed login token (an RS256 JWT) before it could join a room.

Kafka carried events between the backend services.

Peak-Load Handling

The real-time layer kept bursts of votes, joins and reactions from turning into bursts of database writes.

Votes were saved in one write once more than 50 were waiting, or after 1 second of quiet.

Viewers were counted in Redis, each account once, with at most one database write per stream every 3 seconds. When a viewer disconnected, the server sent a leave for every room the viewer was in, so counts stayed accurate.

Hearts went straight from the sender's socket to the room and were never stored. Chat messages were saved; reactions were not.

State Snapshot for Late Joiners

A viewer joining a stream already in progress received its current state at once.

The snapshot carried the chat status, the active poll with the viewer's own vote, and the current Q&A.

Viewers who swiped in mid-stream saw the live poll immediately, with no wait for the next update.

Timed Polls and Q&A

Creators ran timed polls and Q&A sessions that the server opened and closed on schedule.

Only the stream's owner could start a poll or a Q&A.

Polls took 2 to 5 options of up to 20 characters, an 80-character question and a timer of up to 1 hour.

Questions could be pinned, answered or skipped.

Poll results and the Q&A's automatic stop ran as delayed jobs on Bull, a job queue built on Redis.

Chat with Background Moderation

Chat messages appeared instantly, and Hive, an AI content-moderation service, checked each one in the background.

A message scoring above 0.5 in any harmful category was flagged for removal. Stream titles were checked before saving, while chat was checked after sending, so moderation added no delay to the conversation.

Creators could delete a message for everyone or switch chat off, and messages were capped at 200 characters.

The app redrew incoming chat at most every 750 ms, and joining a stream that was not live yet retried after 1, 2 and 4 seconds.

Camera-Free Load Testing

The load tests exercised chat, polls and Q&A at scale with no real video in the loop.

Tests sent the video vendor's signed "stream started" webhook themselves, so test streams went live instantly with no video source.

Test commands set spikes of 1,000 simulated viewers in one chat, each sending a message and a reaction every 5 seconds.

Each simulated viewer timed how long its own message took to come back through the room, and failed if it had not joined the chat within 10 seconds.

Each run also counted messages that never came back, and pushed its metrics to VictoriaMetrics, a Prometheus-compatible metrics store, at the 90th percentile.

k6, an open-source load-testing tool, ran inside the Kubernetes cluster through the k6-operator, started from a GitHub form. About 30 poll and 15 Q&A unit tests covered the logic.

Results Achieved

dashboard black

Batched write optimization

High-volume vote bursts were aggregated into batched database writes, preserving zero-lag responsiveness for chat and new viewer joins.

refresh

Real-time state hydration

Late-joining viewers instantly synced with the active stream state, immediately rendering live polls and Q&A data upon connection.

shield

Asynchronous content moderation

Live messages rendered instantly on the client while AI moderation pipelines executed non-blocking background checks to flag harmful content.

Data Transfer

High-concurrency load testing

Staging environments successfully processed simulated spikes of 1,000 concurrent viewers broadcasting messages and reactions every five seconds.

checkmark

Server-enforced session logic

Creators triggered live polls and Q&A events from mobile clients, with the backend strictly enforcing automated closure states and timeouts.

Adding Live Interaction to Your App?

DBB Software engineers build real-time chat, polls and Q&A that keep up when a whole audience joins in.

Contact Us

I have read the principles of personal data protection - Privacy Policy

"Most of our work starts with a 30-minute call where someone describes a product they're trying to ship and one part of the engineering picture they can't get around.

If that's where you are, let's set one up; I'll tell you straight whether we're the right fit.”

Mina Morkos

Business Development Manager

Want a similar outcome for your team?

Ask our AI assistant — it can pull related case studies, talk through the approach, and put you in touch with the team if you want a deeper conversation.

Discuss a similar project