BingoLive.online: how a playful project became a technical laboratory

The origin of the project

I created BingoLive at a time when online casino games were on the rise in France, particularly with the rapid growth of Twitch live streams and the increase in the number of players.

My idea was to build an imperfect but free alternative for people who wanted to enjoy some of those game mechanics without betting real money.

The service would never request a deposit, sell credits or offer redeemable winnings. Its only purpose was to preserve the fun of the draw, the bingo cards and the live experience.

However, I knew that such a solution could not be presented as a way to overcome addiction. A free game does not replace specialized support when a person encounters a real addiction.

My technical goals

When I started this project, I mainly wanted to learn JavaScript at a more advanced level and understand how streaming platforms work.

Streamers at the time mainly broadcast their content on Twitch. To match the habits of the target audience, I wanted to broadcast the draw on the same platform.

The project quickly grew beyond a simple front-end website and required several components that could work together.

The initial architecture

The first version of BingoLive used an architecture made up of several separate components.

The frontend displayed the bingo cards, latest number, game history and chat. APIs exposed the current game state to the client, while a server-side orchestrator started each round, managed timers and drew the numbers.

The server remained the source of truth. The client never decided the outcome of a draw itself. It retrieved information from the APIs and updated its display.

This separation prevented each browser from generating its own version of the game and ensured that every user saw the same synchronized state.

Twitch broadcasting

For the Twitch live stream, a Raspberry Pi displayed the draw engine in full screen. The stream was then encoded in H.264 and sent to Twitch through the streaming pipeline.

Roger Chaudet of Spatiograph designed the UI/UX and the graphical assets used for the draw, including the bingo balls. His work gave the project a distinctive visual identity.

Twitch provided the visual and community experience, but the platform naturally introduced latency. The video therefore could not serve as the authoritative technical state of the game.

Real-time synchronization

One of the most interesting aspects of the project concerned the synchronization between the draw engine, the Twitch live stream and the users' browsers.

With each new number, the orchestrator updated the state of the game. Clients retrieved this information through APIs and immediately displayed the last number drawn.

This visual aid was essential, because the Twitch live stream could arrive with several seconds of delay. Players could therefore continue to follow their cards accurately, even if the video was not perfectly synchronized.

This project allowed me to work on several typical issues of distributed systems:

• current state management;
• order of events;
• reconnection of a client during the game;
• recovery of draw history;
• latency management;
• consistency between several connected clients.

Generating bingo cards

Generating the cards also required a real algorithm. I didn't want to just place random numbers in a grid.

The cards had to respect the traditional French loto layout: distribution of numbers by columns, defined number of filled cells per row and absence of inconsistent duplicates.

Users could receive multiple cards during a game. The system therefore had to:

• generate valid cards;
• link them to the correct user;
• maintain their state throughout the game;
• automatically check the numbers already drawn;
• detect winning combinations.

The whole system relied on APIs connecting the frontend, backend and orchestrator.

Login, chat and localization

The target audience included people who were not very comfortable with computers. I therefore integrated simplified sign-in via Facebook in order to avoid creating a new account with an additional password to remember.

Chat was also an important building block. Bingo is a social game: without interaction between players, the experience would quickly resemble a simple number generator.

I also implemented country detection and interface localization. To keep the experience consistent, chat also needed localization, either through language-specific rooms or suitable translation logic.

This work covered internationalization, locale detection, translated content and the limitations of automatic geolocation.

Scaling up and load balancing

At the height of its activity, BingoLive attracted around 1,300 users. This figure does not necessarily correspond to 1,300 simultaneous connections, but it was enough to reveal the limits of the initial architecture.

I had to work on server-side load balancing, service monitoring, and removing multiple single points of failure.

This was one of my first hands-on experiences with load balancing in a real-time application.

Data retrieved via Google Analytics also showed a significant portion of mobile users. So I reworked the user interface to make it truly responsive and make the cards usable from a smartphone.

VPS, local network and OpenVPN

BingoLive used a hybrid architecture.

The front end, APIs and orchestrator were hosted on my Ionos VPS. The streaming pipeline, built around a Raspberry Pi and H.264 encoding, ran on my local network.

It was therefore necessary to maintain a permanent connection between these two infrastructures. I didn't want to open multiple ports on my local network or directly expose internal services to the Internet.

I set up an OpenVPN server to create a permanent tunnel between my local infrastructure and the VPS. The different components could thus communicate through a common private network.

This design gave me hands-on experience with:

• network routes;
• persistent VPN tunnels;
• communication between a VPS and a LAN;
• reconnection after an outage;
• reducing the public attack surface.

An architecture that has become too complex

What began as a simple project for learning JavaScript evolved into an architecture combining a frontend, backend, APIs, an orchestrator, a VPN, a Raspberry Pi, an H.264 encoding pipeline and Twitch broadcasting.

The system worked, but every startup and incident required hands-on maintenance.

I let this architecture run for about six months before having to reassign the Raspberry Pi to other projects.

Bringing the entire infrastructure back online solely for BingoLive eventually took too much time, so the project remained dormant for a while.

Relaunching with vibe coding

Thanks to vibe coding, I finally found the time to return to the project and modernize its architecture.

The first significant change was the cessation of broadcasting via Twitch. The screen that was previously displayed on the Raspberry Pi and sent to the platform is now rendered directly in each user's browser.

I also took the opportunity to add several mini-games, including a free version of blackjack, pachinko and a wheel inspired by casino games.

These games use free virtual points only. They do not allow deposits, withdrawals or prizes with monetary value.

The limits of the project

BingoLive can be a free alternative for people who want to experience some of these game mechanics without risking losing money.

However, this type of service should not be presented as a medical solution or a withdrawal method. Random draws, animations and points can still reproduce some of the sensations associated with gambling.