Technical notes

Stats for
Nerds

How Tambola actually works under the hood.

01Overview

Overview

The frontend is only the interface. It renders tickets, animates numbers and collects taps — nothing more. Every decision that matters happens elsewhere.

The backend is the heart of the game. It owns game state, calls the numbers, generates and validates tickets, resolves claims and determines winners. If the browser closed mid-game, the game would carry on without it.

02Game Engine

Game Engine

Player
Frontend
Spring Boot Backend
Game Engine
PostgreSQL
WebSocketAll Players

Players never decide whether a number was called or whether a claim is valid. Actions travel inward to the engine; results travel outward over WebSocket to every connected player at once.

03Ticket Generation

Ticket Generation

Every player receives three generated ticket choices before entering the game lobby. They pick one; the selection is persisted server-side and becomes the only ticket that can ever win for them.

  • 3 × 9 Tambola ticket grid
  • 15 numbers per ticket
  • 5 numbers per row
  • Column-specific number ranges
  • Backtracking finds valid placements
  • Empty cells represented as 0
  • Returned to the client as a matrix
  • Selected ticket persisted on the server

3 × 9 · 15 numbers · 5 per row

5023047062730014035055079818029052068090
1–910–1920–2930–3940–4950–5960–6970–7980–90

04Server Authority

Server Authority

The browser displays the game.
The server decides the game.

  • Server generates called numbers
  • Numbers can never repeat
  • Server tracks the full call sequence
  • Server controls game state
  • Server validates every Housie claim
  • A client cannot declare itself a winner

05Real-Time Gameplay

Real-Time Gameplay

REST APIs handle deliberate player actions — creating and joining rooms, starting games, claiming Housie. Each is a request with a definite answer.

WebSocket over STOMP handles everything that happens on its own schedule. The server broadcasts events; clients only react.

PLAYER_JOINED
GAME_STARTED
NUMBER_CALLED
GAME_PAUSED
CLAIM_RESULT
GAME_RESUMED
GAME_COMPLETED

06Winning & Validation

Winning & Validation

Housie pressed
Claim sent to backend
Game pauses
Backend validates ticket
VALID → WinnerINVALID → Disqualified
Game resumes or ends

Current winning methods

  1. 01Early Five
  2. 02Top Line
  3. 03Middle Line
  4. 04Bottom Line
  5. 05Full House

07Data & Persistence

Data & Persistence

PostgreSQL stores everything required to keep a game alive across reconnects and restarts. Ticket matrices are stored as JSONB.

  • Rooms
  • Players
  • Tickets
  • Games
  • Called numbers
  • Claims

08Tech Stack

Tech Stack

Frontend
React
Backend
Java + Spring Boot
Database
PostgreSQL
ORM
Hibernate / Spring Data JPA
Real-time
WebSocket + STOMP
Architecture
REST APIs + event-driven real-time updates

Pretty interface.
Serious backend.

Every number, every claim and every winner is decided by the game engine — not by the browser.

Back to home