Plataforma
Quatro componentes, dois planos
Um plano transacional — o que o jogador usa, o que decide o jogo e onde o dinheiro é registrado — e um plano de prontidão, que prepara evidências sem tocar na aposta. Selecione um componente ou um contrato para ver responsabilidade, dados e fonte de verdade.
Arquitetura interativa
Fluxo transacional · jogador → BetFront → Game Provider → BetBackoffice
Trilha paralela de prontidão · fora do fluxo da aposta
O MotorGLI não recebe, altera nem observa transações de jogador: ele estrutura a avaliação de prontidão de sistemas — inclusive dos três componentes acima.
Responsabilidade
Executa os jogos no servidor: sessão, round, aposta, cashout e settlement, com trilha por rodada.
Resultado para a operação
O resultado é decidido, registrado e verificável no servidor — nunca no navegador.
Descrição em texto do diagrama
- O jogador usa o BetFront.
- O BetFront pede ao Game Provider a sessão do jogo por uma chamada assinada e recebe a URL do jogo.
- O Game Provider executa o jogo no servidor e movimenta a carteira pela Wallet API do BetBackoffice, de forma idempotente.
- O BetBackoffice mantém a carteira, as decisões operacionais e a auditoria.
- Em paralelo, e fora desse fluxo, o MotorGLI estrutura a avaliação de prontidão: cenários, findings, reteste e pacote de submissão.
Jornada 1 · plano transacional
Do jogo aberto à auditoria
Jogador abre o jogo, sessão, aposta, débito idempotente, round no servidor, cashout ou crash, crédito e auditoria. Percorra os passos e alterne entre a visão de negócio e a técnica.
Jornada 2 · plano de prontidão
Da versão candidata ao pacote de submissão
Versão candidata, avaliação, findings, evidências, reteste e pacote. Esta trilha é independente: o MotorGLI não participa da aposta e não emite certificação.
Regras da arquitetura
Fronteiras que não se cruzam
Cada componente tem uma fonte de verdade
Carteira e saldo pertencem ao BetBackoffice; estado de jogo pertence ao Game Provider; o processo de avaliação pertence ao MotorGLI.
Nenhum componente escreve no banco de outro
O Game Provider movimenta dinheiro apenas pela Wallet API, com idempotência e correlação.
O navegador só apresenta
Resultado, prêmio e saldo são decididos e registrados no servidor; segredos de integração não chegam ao cliente.
A conformidade fica fora do runtime
O MotorGLI estrutura a prontidão sem alterar o caminho transacional.
Quer ver como isso se encaixa na sua operação?
Descreva o que você já tem e o que precisa. Mapeamos os componentes e os contratos necessários.