Home/About/aboutProjects/projectsLab/backend-labiGaming/i-gamingBlog/blogRésumé/resumeContact/contact
iGaming lab
API-backed demo

Keno Fast

REST · 20-of-80 draw
Server-backed keno engineNext
native.typescript / AGT

Keno Fast

An interactive number board backed by secure server-side drawing and paytable evaluation.

connecting
Demo credits1,000.00
Selected0 / 10
Last payout0.00
Source RTP95.6170%
number.matrix / 20-of-80awaiting draw
Select 1–10 numbersREADY

Select at least 1 number.

engineering.case-study

Inside the Keno Fast system boundary.

What the player experiences, what the implementation actually owns, and where production responsibilities would begin.

01

Game background

Keno Fast is another 20-of-80 model, supporting 1–10 selections and paytable rows that include distinctive low-hit returns. It demonstrates why a game engine must treat each selection count as its own probability and payout configuration.

02

How the game works

  1. Select 1–10 unique board numbers.
  2. Submit a stake and validated selection to the backend.
  3. The service draws 20 unique numbers and counts hits.
  4. The selection-count row and hit column determine the payout multiplier.
03

Backend architecture

Keno Fast reuses the same session, validation, state, and secure sampling boundaries as Fire Keno while supplying its own selection limits and paytable definition.

ClientREST APISelection validationCrypto drawPaytableResult
04

System boundaries

Game Client
Presentation, input, accessibility, and demo-credit display.
REST API
Request validation and routing into one isolated game session.
Game Session
Ephemeral configuration and the previous authoritative result.
Game Engine / RNG
Outcome generation, game rules, win evaluation, and result contracts.
Keno Fast Paytable
Selection-specific multiplier rows, including configured zero-hit outcomes.
05

Critical engineering decisions

  • Support one-number play explicitly.
  • Treat zero-hit multipliers as paytable data rather than a scanner special case.
  • Reuse secure sampling without sharing mutable game sessions.
  • Test the distinctive single-number return deterministically.
06

Failure handling

  • A client disconnect does not rewrite a completed server result; reconnecting requires the session identifier while it remains in memory.
  • An unknown or expired session is rejected instead of silently creating a replacement outcome.
  • A timed-out spin or draw should not be blindly retried as though commands were idempotent; these demos do not yet persist command identifiers.
  • The browser’s virtual credits are not a ledger. If UI credit state is lost, it cannot be reconstructed from these focused game-engine modules.
07

Fairness / RNG

The backend draws without replacement through the shared cryptographic sampler. It is server-authoritative but not certified or provably fair.

08

Conceptual data model

GameSession- gameId- betAmount- selectedNumbers- lastActivity
DrawResult- drawnNumbers- selectedNumbers- screen
Win- selected- hits- multiplier- payout