kingapostas: servidores e APIs

A operação da KING Apostas roda sobre três regiões de nuvem simultâneas — São Paulo, Frankfurt e Ashburn — com réplicas síncronas do estado de jogo. Cada região mantém um cluster Kubernetes com nós dedicados a matching, carteira e feed de odds; o balanceamento usa latência real do cliente, não geografia aproximada. O resultado prático: usuários brasileiros fecham a aposta contra o nó de São Paulo em menos de 40 ms, enquanto o registro contábil replica para as duas outras zonas antes da confirmação na tela. O kingapostas não trata o servidor como diferencial de marketing, e sim como infraestrutura de disponibilidade. O SLA interno é de 99,95% mensal, com orçamento de erro de aproximadamente 22 minutos; cada minuto excedente dispara revisão de post-mortem pública para times parceiros. Bancos de dados distribuídos como CockroachDB mantêm consistência forte nas transações de saldo, enquanto Cassandra absorve telemetria e histórico de cotações.

Odds e carteira conversam por duas camadas distintas. A primeira é um canal de streaming WebSocket, que empurra alterações de mercado em tempo real; a segunda é uma API REST idempotente, usada para enviar apostas, consultar saldo e solicitar saques. Cada requisição carrega uma chave de idempotência gerada no cliente, o que impede que uma reconexão de rede duplique o mesmo ticket. O catálogo de endpoints segue especificação OpenAPI 3.1, com versionamento semântico e deprecação anunciada com 90 dias de antecedência. Parceiros que operam via API — afiliados, provedores de dados esportivos, gateways de pagamento — recebem limites por minuto definidos por contrato: normalmente 600 requisições por segundo no pico, 120 em regime estável. Excedentes retornam HTTP 429 com cabeçalho Retry-After, nunca bloqueio silencioso. Internamente, o kingapostas expõe métricas de latência p95 e p99 por endpoint para garantir alta performance constante durante as rodadas.

Toda aposta é um evento com timestamp. Para que dois servidores concordem sobre a ordem deles, os nós sincronizam relógios via NTP, com desvio máximo tolerado de 5 ms; acima disso, o nó sai do pool de aceitação. O fluxo segue por tópicos Kafka particionados por evento esportivo, e cada partição processa eventos em ordem estrita — o que evita o clássico cenário de uma aposta aceita depois de um gol já registrado. A janela de fechamento de mercado é o ponto mais sensível. Quando o feed marca um lance, o comando de congelamento leva entre 120 e 200 ms para alcançar todas as regiões. Cliques nesse intervalo entram em fila de verificação e podem ser anulados com estorno integral, regra que consta nos termos do kingapostas. Cash-out e apostas ao vivo herdam essa mesma lógica rigorosa. Um job de reconciliação roda a cada 15 minutos, comparando o livro de apostas com os extratos bancários de forma segura e transparente.

Circula a ideia de que cassino ou casa com servidor mais potente entrega cotações melhores. Isso não se sustenta. Preço de odd vem da margem embutida e da modelagem probabilística do provedor de dados, não da CPU que processa a requisição. Duas plataformas com hardware idêntico podem oferecer 1,85 e 1,92 no mesmo mercado — a diferença está na margem, no risco assumido e no volume que a casa aceita, não no processador. Onde a infraestrutura realmente muda a experiência do apostador é em três pontos mensuráveis: tempo de aceitação do bilhete, precisão do congelamento de mercado em lances duvidosos e velocidade de crédito em saques via Pix. Esses três itens são operacionais, verificáveis em teste e independentes do tamanho da odd oferecida. Vale desconfiar também do mito oposto, de que servidor próprio seria sinônimo absoluto de segurança contra ataques cibernéticos modernos.

Feed externo falha. É questão de quando, não de se. O sistema trabalha com três provedores de dados esportivos em paralelo e um árbitro interno que decide qual cotação é canônica por mercado. Se o provedor primário para de responder em 800 ms, o tráfego migra para o secundário e o mercado entra em modo somente leitura: apostas novas ficam suspensas, as já registradas permanecem válidas. Há também proteção contra o oposto — dado errado chegando rápido. Um filtro estatístico rejeita variações de preço acima de 12% em menos de dois segundos, sinal típico de erro de feed. Cotações bloqueadas por esse filtro ficam em quarentena por 30 segundos antes de voltar ao ar. Para o usuário, o sintoma é uma tarja de mercado suspenso e o botão desabilitado. Não há perda de saldo nesse processo: a carteira só é debitada na confirmação exata do matching de apostas realizado no servidor principal.

Toda aposta gera trilha de auditoria. O log imutável guarda ID do bilhete, ID do usuário, mercado, cotação aceita, timestamp em UTC com milissegundos e hash do payload. Os dados ficam retidos por cinco anos, prazo alinhado às exigências de órgãos reguladores de apostas de quota fixa no Brasil. Acesso a esse log é segregado: analistas de risco veem o próprio mercado, times de compliance veem tudo, engenharia vê apenas metadados. Há limites técnicos que pouca gente conhece. O tamanho máximo do bilhete simples é definido por mercado e por conta, e o teto de payout por evento costuma ser o que trava apostas grandes — não o saldo. Requisições de saque passam por antifraude com verificação de dispositivo e IP, e o KYC é acionado acima de determinados valores conforme regra vigente. A infraestrutura também sustenta testes de carga públicos antes de eventos de grande porte, simulando milhares de acessos simultâneos sem qualquer perda de dados.