lightbulb Cresça de forma simples. Multiplique de forma rápida.
Você não reconstrói o cassino para cada novo cliente — você o multiplica. Pegamos a plataforma de cassino existente e já testada e fazemos uma cópia separada e privada para cada cliente. Cada cópia roda no seu próprio espaço isolado, com banco de dados, senhas de acesso, certificado de segurança, endereço web e regras do país próprios. Os clientes gerenciam tudo por um único sistema de administração compartilhado; os jogadores só enxergam o cassino do próprio cliente, nunca o de outro.
- Tenant
- — o cassino privado de um cliente.
- White-label
- — o cliente opera esse cassino com a própria marca.
- Control-plane
- — o sistema que cria e gerencia cada tenant.
- Provisioning
- — a configuração automatizada de um novo tenant.
tune Decisões-chave
Control-plane por cima do runtime existente — reuso máximo, risco mínimo.
Silo: cada cliente recebe uma cópia completamente separada com banco de dados próprio — sem precisar reescrever nenhum código existente.
Clusters Kubernetes existentes; Cloudflare na borda para roteamento, WAF e TLS.
White-label B2B — operadores externos como tenants, cada um com sua marca e cobrança.
Cada cliente é definido como código no Git; uma ferramenta de automação (ArgoCD) mantém o sistema em produção sempre alinhado com essa definição.
O cassino de um segundo cliente, funcionando de ponta a ponta: criado por um único comando e completamente separado do primeiro.
account_tree Contexto do sistema
Existem duas camadas. O control-plane é onde você cria e gerencia clientes. O data-plane é o conjunto de cassinos em execução — uma cópia separada por cliente. Os clientes usam o control-plane; os jogadores acessam apenas o próprio cassino.
apartment Por que isolamento "silo"
Em um negócio regulado, manter os dados de cada cliente fisicamente separados é mais seguro do que misturar tudo nas mesmas tabelas. O banco de dados de cada cliente fica no próprio espaço, pode residir no país exigido pela licença, e um problema com um cliente nunca afeta os outros. Também reaproveitamos o código existente do cassino sem precisar reescrevê-lo. A contrapartida: o esforço real se concentra em automatizar a criação de cada cópia separada.
| Critério | Silo (escolhido) | Pooled + RLS |
|---|---|---|
| Isolamento de dados | Físico (mais forte) | Lógico (RLS) |
| Blast radius | 1 tenant | Todos |
| Reuso do código atual | Total | Refactor invasivo |
| Custo por tenant | Maior | Menor |
rocket_launch Fluxo de provisioning
A configuração é idempotente — ou seja, você pode rodá-la quantas vezes quiser e sempre chega no mesmo estado correto, sem duplicatas. Se um passo já foi concluído, ele é simplesmente confirmado e pulado.
cloud A borda Cloudflare
O mesmo processo de configuração também prepara o ponto de entrada público no Cloudflare. Cada cliente recebe seu próprio endereço web e certificado HTTPS, mais um pequeno programa rodando na borda do Cloudflare que reconhece o endereço, encaminha o visitante para o cassino certo e aplica a marca daquele cliente. O sistema também adiciona filtros de segurança e limites de tráfego por cliente. Tudo isso é escrito como código com Terraform, então é repetível.
No conjunto, o visitante chega ao Cloudflare, que verifica e filtra a requisição e a encaminha para o cassino do cliente certo rodando dentro do cluster:
dns Onde rodar: on-premise, AWS ou Cloudflare
O cassino em si roda em Kubernetes — no seu próprio hardware (on-premise) ou em uma nuvem gerenciada como a AWS. A Cloudflare fica sempre na frente, como a porta de entrada pública. A mesma ferramenta de configuração e o mesmo pacote funcionam nas três; só muda o lugar, então você pode começar on-premise e migrar para a nuvem depois sem reescrever nada.
Seus próprios servidores. Controle máximo e os dados ficam no seu prédio.
- A ferramenta cria o namespace, o banco, os segredos e o certificado.
- O GitOps implanta o pacote do tenant.
- O gate de segurança e compliance roda; o cassino entra no ar.
Nuvem gerenciada. Escala para cima e para baixo sob demanda, menos hardware para cuidar.
- O Terraform monta a rede, o Kubernetes gerenciado e o banco gerenciado.
- O mesmo pacote implanta cada tenant.
- O mesmo gate roda; o cassino entra no ar.
A porta de entrada global — não é onde o cassino roda, mas o que todo jogador acessa primeiro.
- O Terraform configura o endereço web, o certificado e as regras de segurança.
- Um programa na borda encaminha cada jogador ao tenant certo e aplica a marca.
- O tráfego é filtrado e encaminhado ao runtime escolhido.
| K8s on-prem | AWS | Cloudflare | |
|---|---|---|---|
| Papel | Roda o cassino | Roda o cassino | Porta de entrada |
| Controle | Total | Compartilhado (gerenciado) | Só config da borda |
| Escala | Comprar hardware | Elástica, sob demanda | Global, automática |
| Custo | Fixo (hardware próprio) | Paga conforme usa | Baixo / por requisição |
| Local dos dados | No seu prédio | Escolhe a região | Borda (só cache) |
| Esforço de operação | Você opera | Menor (gerenciado) | Mínimo |
| Latência ao jogador | Regional | Regional | Borda global |
timeline Ciclo de vida do tenant
shield Isolamento por tenant
verified_user Regulação, segurança e compliance
Um cassino novo não entra no ar antes de passar por um gate automático. Primeiro vêm as verificações de segurança: vulnerabilidades conhecidas no software, senhas vazadas, configuração insegura e a confirmação de que o cassino está travado no nível dos pods e da rede. Depois vêm as verificações de compliance, ligadas ao país do cliente: regras de identidade e antilavagem de dinheiro, limites de jogo responsável, uma trilha de auditoria completa e os relatórios que o regulador exige. Se algo falha, o cassino continua desligado e o time é avisado.
As regras exatas vêm da configuração de país de cada cliente. O Brasil, por exemplo, exige checagem de identidade por CPF, pagamentos via PIX e relatório SIGAP em tempo real; Malta (MGA) e o Reino Unido (UKGC) têm suas próprias exigências de identidade, pagamento e relatórios. Um cassino demo roda sem dinheiro real e com verificações mínimas.
map Roadmap até o MVP
- Uma definição de tenant no Git
- Valores de chart reutilizáveis por marca
- Modelo base de segredos e certificado
- Namespace, NetworkPolicy e banco
- OpenBao, cert-manager e Helm release
- Migrations e smoke test conectados
- Cadastro, depósito e aposta funcionam no tenant B
- Saldos e dados de jogador ficam separados
- Teste automático de isolamento bloqueia acesso cruzado
- Status, billing e uso por tenant
- Ações de ciclo de vida
- Evidência de compliance por jurisdição
O primeiro marco é atingido quando: um único comando cria um segundo cassino completamente separado do zero; rodar esse comando de novo não muda nada; um jogador consegue se cadastrar, depositar e apostar nele; o saldo desse jogador fica completamente separado do primeiro cassino; e um teste automatizado prova que os dois cassinos não conseguem acessar a rede, os dados nem os segredos um do outro.