Online gaming platform with hybrid lottery/poker mechanics and real-time play

Summary

An online gaming operator needed a proprietary platform — not based on white-label solutions — to offer a product with a hybrid mechanic combining elements of lottery and poker. The work involved designing and building the entire architecture from scratch: game backend, player frontend and administration panel, built on .NET and SignalR, with a focus on real-time synchronization, traceability and operational stability. The platform ran in production for approximately two years.

Context

The client operated in the online gaming sector and wanted to differentiate themselves from the standard catalog of external providers with a proprietary product with specific rules. The mechanic combined the timing and randomness of a lottery with decision elements from card games, generating a usage profile very different from a conventional casino: activity peaks concentrated around game events, multi-minute sessions with continuous interaction and a strong expectation that what was shown on screen was exactly what the server had recorded.

The technical environment was based on the Microsoft stack, which shaped architecture, hosting and tooling decisions. There was no existing system: the starting point was a functional document and UI prototypes, and the destination was an operable, auditable and maintainable platform for a small team.

Problem

Building this type of product from scratch requires solving several problems at once:

• The game mechanic required shared, consistent state between all players connected to the same game, with changes every few seconds.
• Any mismatch between what the user saw and what the server recorded could generate disputes and trust issues.
• Being a money-based gaming product, traceability of every action (bet, event, result, payout) was not optional.
• The administration panel had to allow operating the service live: reviewing active games, acting on accounts, querying history and diagnosing incidents without direct database access.
• All of this had to be supported by a small team without over-engineering, because the product still had to validate its market.

Goals

• Build a functional, stable gaming platform with a real-time user experience.
• Guarantee consistency between server state and the client view.
• Ensure full auditability of critical actions.
• Deliver an administration panel usable by non-technical staff.
• Maintain a codebase manageable by a small team throughout the product’s expected lifecycle.

Technical approach

The architecture was organized around three clear pieces: the game backend, the real-time layer and the interfaces (player and administration).

• .NET / C# backend with MVC as the application core. Game logic (rules, valid states, transitions) was separated from the web layer, so rules could evolve without touching controllers or views.
• SignalR as the real-time layer to broadcast game events (round opening, state changes, results) to all connected clients. Choosing SignalR over more exotic solutions was justified by its natural integration with the stack and by reducing the number of operational moving parts.
• Authoritative state model on the server: the client never decides the outcome of anything. The frontend reacts to events emitted by the server, which avoids inconsistencies and simplifies the security model. Player actions are sent as intentions; the server validates them and returns the new state.
• Idempotent and traceable operations on everything that touches balance or result: each critical action is recorded with a unique identifier, timestamp and sufficient context to reconstruct what happened.
• Player frontend built on MVC views and client-side JavaScript, subscribed to SignalR hubs. The focus was not a complex SPA but a reactive, lightweight and reliable view.
• Administration panel as a separate application within the same project, with its own access control, views for monitoring active games, user management and history querying. The priority was that the operations team could work without requesting SQL queries from the developer.
• Relational persistence with SQL Server, explicitly modeling game, round, move and result entities so that any subsequent audit would be straightforward.

Decisions and trade-offs

The most important decision was not using a white-label solution and building the product custom. This increased the initial cost, but it was the only way to implement the specific hybrid mechanic that differentiated the client.

Within the development, the following were deliberately avoided:

• A microservices architecture. For a small team and a product still validating its market, a well-structured modular monolith offered a better balance between delivery speed and maintainability.
• A heavy SPA on the frontend. Server-rendered views with reactive islands via SignalR covered the requirements without adding a full frontend stack to maintain.
• Game logic on the client. While it would have reduced perceived latency, it would have opened the door to manipulation and divergence between clients.

In return, the assumption was made that the system would scale vertically and that scaling SignalR horizontally (with a backplane) would be a later decision if traffic justified it. That decision never became necessary during the product’s life.

Result

The platform ran in production for approximately two years, supporting the client’s operations without rewrites. Notable outcomes:

• Stable real-time gaming experience with consistent state between players.
• Full auditability of critical actions, simplifying incident and dispute resolution.
• Administration panel sufficient for the operations team to manage day-to-day without technical intervention.
• Codebase manageable by a small team throughout the entire product lifecycle.
• Reasonably short change cycle for game rules thanks to the separation between domain and web layer.

Tech stack

• .NET / C#
• ASP.NET MVC
• SignalR
• SQL Server
• Client-side JavaScript
• IIS / Windows hosting

What this case demonstrates

This case demonstrates the ability to take a product from a functional document to a platform operated in production for years, handling architecture design, backend, real-time layer, frontend and administration tooling simultaneously. It shows judgment in choosing technologies proportional to the problem, separating domain logic from infrastructure details and making realistic scalability decisions based on where the product actually is.

---

Building a digital product where real-time interaction, traceability and reliability are critical? I can help you design the architecture and accompany development from the initial phase through to production.