Estrutura de Banco de Dados

A salvaguarda de informações do Cassino é executada de forma poliglota: armazenamos dados onde fazem mais sentido de acordo com a velocidade pretendida, embora existam certas heranças desnecessárias na fatura final da cloud.

1. Bancos Críticos (Transacionais)

O motor do dinheiro usa PostgreSQL. A modelagem possui colossais 129 entidades espalhadas no TypeORM (users, wallets, bets, deposits).

• Wallets Isoladas: Existem carteiras wallets atreladas separadamente paras o dinheiro "Dinheiro Real" (balance) e carteiras secundárias ligadas a bônus ou promocoões de indicação (credit).
• Em apostas (Bets), é gerada uma fatura consolidadora chamada de unified_bets, que junta a aposta desportiva, a aposta de cassino infinGame ou a roleta, permitindo uma rastreabilidade mais linear na hora de auditar contas suspeitas.

2. RealTime & Filas (Eventing)

• Redis: Gerencia sessão rápida e atua como sentinela em "RedLocks" (travas virtuais) impedindo, por exemplo, que duas apostas vindas num piscar de olhos de um slot fraudulento descontem dobrado da conta do jogador; só passa um bloqueio por vez.
• RabbitMQ: Transporta mensagens assíncronas. Uma notificação de depósito pago que vem de fora é postada nessa "Fila" e vai pra retaguarda do sistema até ser computada, deixando a ponta do funil de fora liberta das travadas da nuvem.

3. Débito no Arquivo (MongoDB Cloud)

Os dados apontam que o sistema consome ativamente uma fatia computacional alugando MongoDB exclusivamente para logging event e "dumpar" arquivos estranhos. O PostgreSQL comporta formatações não-relacionais muito robustas chamadas JSONB. É encorajado remover esse motor NoSql caso seu uso seja raso para otimizar os custos com a Amazon AWS.