Bra Bet: Latência e API

A BraBet opera com servidores de borda em São Paulo e Fortaleza e trata cada aposta como transação com orçamento de tempo definido. O caminho completo — toque na tela, validação de saldo, verificação de limites, aceite da odd e confirmação — precisa caber em menos de 300 ms para que o usuário não perceba espera. Desse total, cerca de 40 ms são consumidos pelo trajeto de rede entre o celular e o ponto de presença mais próximo; outros 60 ms ficam com a consulta ao cache em Redis, onde vivem odds e mercados ativos. O núcleo transacional, escrito sobre PostgreSQL com filas no Kafka, responde em 70 ms sob carga normal. A interface usa conexões persistentes WebSocket em vez de polling, o que reduz o tráfego de cabeçalhos e permite empurrar atualizações de placar sem nova requisição. O TTFB medido no Brasil fica entre 120 ms e 180 ms em 4G estável.

Cada milissegundo tem preço. Em mercados ao vivo, a cotação muda dezenas de vezes por minuto, e uma aposta enviada com 400 ms de atraso pode chegar ao servidor com odd já expirada. O resultado prático é o erro de 'odd alterada': o usuário toca em 1,85, o sistema processa 1,79 e a operação é devolvida para confirmação. Em picos de jogo, essa devolução responde por 6% a 12% das tentativas recusadas no bra bet, segundo monitoramento interno. O custo não é apenas técnico. Cada rejeição obriga o apostador a decidir de novo, e a fricção derruba a conversão de cliques em apostas confirmadas. Um teste A/B com resposta de 180 ms contra 620 ms mostrou queda de 9% no volume no grupo mais lento. Menos tempo total também diminui a carga nos servidores, porque menos requisições se repetem.

Três pontos concentram quase todo o atraso percebido. O primeiro é o feed de odds: provedores como Sportradar e Betradar entregam atualizações em fluxos que variam de 150 ms a 900 ms, e o sistema depende desse intervalo para suspender mercados. O segundo são as validações síncronas que rodam antes do aceite — saldo, limite de exposição, autoexclusão e checagem de KYC. Cada consulta externa adiciona tempo ao caminho crítico. O terceiro está no aparelho do usuário.

• Conexão 4G congestionada eleva o ping de 40 ms para 250 ms.
• App desatualizado reaproveita bibliotecas antigas de WebSocket.
• Modo economia de bateria reduz a frequência de atualização da tela.

Nenhum desses fatores aparece sozinho: em horário de pico, os três se somam e a aposta demora mais de um segundo para confirmar. A engenharia trata cada camada com ferramentas diferentes — cache local para odds, pré-cálculo de limites no servidor e verificação preguiçosa de KYC quando o risco é baixo.

O caminho de uma aposta aceita cabe em etapas mensuráveis, cada uma com teto de tempo definido.

1. Toque no botão: o app envia identificador de mercado, seleção e valor em até 10 ms.
2. Autenticação: o token da sessão é validado na borda; sessões expiradas param aqui.
3. Saldo e limites: leitura no cache e cálculo de exposição por mercado rodam em paralelo, com teto de 50 ms.
4. Conferência da cotação: odd e carimbo de tempo são comparados ao snapshot vigente; divergência devolve pedido de nova confirmação.
5. Escrita transacional: a aposta recebe identificador único, entra no banco relacional e publica evento no barramento.
6. Resposta: o canal persistente devolve o comprovante e a tela atualiza sem recarregar.

Quando uma etapa estoura o teto, o sistema devolve erro explícito com código e motivo, em vez de deixar o apostador na dúvida. Medir cada trecho permite comparar versões da interface antes de liberá-las para todos.

Boa parte do atraso não nasce dentro de casa. Provedores de odds, gateways de pagamento, bureaus de KYC e serviços de geolocalização entram no caminho crítico com SLAs que variam de 99,5% a 99,99%, e cada um deles pode adicionar de 80 ms a 600 ms. Quando a bra bet mede o tempo total de confirmação, entre 25% e 40% dele pertence a terceiros. A resposta técnica é padronizada no mercado: timeouts curtos, tentativas idempotentes e disjuntores que cortam a chamada depois de falhas consecutivas. Se o provedor de odds atrasa, o sistema passa a trabalhar com o último snapshot válido e suspende apenas os mercados mais voláteis, em vez de derrubar a plataforma inteira. Pagamentos seguem lógica parecida: o depósito via Pix é confirmado pelo PSP, mas o crédito local é liberado com base em evento assinado, não em consulta repetida. Dependência externa sem plano de degradação é o erro mais caro de uma operação de apostas.

Em dia de clássico, a média mente. O p50 pode ficar estável em 110 ms enquanto o p95 salta para 340 ms e o p99 passa de 900 ms. São esses percentis que revelam a experiência real de quem aposta nos minutos finais. Monitoramento com Grafana e Datadog roda sobre métricas coletadas na borda, no balanceador e no banco, com amostragem de 10 segundos. Quando o volume de requisições multiplica por oito, o escalonamento automático adiciona instâncias em cerca de 90 segundos — tempo suficiente para uma fila crescer se o feed de odds também estiver sob pressão. Testes de carga com k6 e Locust reproduzem picos de 20 mil apostas por minuto antes de cada rodada grande. O orçamento de erro mensal fica em 0,1% do tempo, e qualquer estouro gera alerta imediato para o time de plantão. Sem essa leitura por percentil, a operação otimiza a média e ignora justamente o usuário que mais aposta.

O feed de cotações chega em fluxos de snapshot e deltas, e cada pacote precisa ser aplicado na ordem correta para que a odd exibida corresponda à odd registrada no aceite. Diferenças de relógio entre servidores são corrigidas por NTP, mas desvios de 200 ms ainda aparecem em ambientes virtualizados e podem inverter a ordem de dois eventos. Por isso, cada atualização carrega carimbo em ISO 8601 com milissegundos e número de sequência. Existe também a reconciliação periódica: a cada 30 segundos, o sistema compara estado local e estado do provedor e suspende mercados divergentes. É esse mecanismo que evita pagar 2,10 por um mercado que o provedor já havia travado em 1,95. O cashout depende do mesmo pipeline, com tolerância de dois segundos entre a cotação mostrada ao cliente e a resposta final. Quando a diferença ultrapassa o limite, o pedido é recusado em vez de aceito com prejuízo.

Desde a Lei 14.790/2023 e das portarias da Secretaria de Prêmios e Apostas do Ministério da Fazenda, a operação precisa guardar registros de apostas, recusas, logins e transações por pelo menos cinco anos. Na prática, isso significa logs em armazenamento imutável, com carimbo de tempo sincronizado e vínculo entre identificador de aposta, sessão e dispositivo. A bra bet mantém esses dados em repositórios com política de escrita única, de modo que nenhum ajuste posterior altere o histórico. Auditorias externas conferem três pontos: integridade do gerador de números aleatórios, correspondência entre odd exibida e odd liquidada, e precisão do carimbo temporal. Laboratórios como GLI, BMM e eCOGRA emitem os laudos usados nesse processo. A LGPD entra em paralelo, limitando o uso de dados pessoais a finalidades declaradas, o que obriga a separar telemetria de desempenho de informação identificável. Latência sem trilha auditável não serve para nada em mercado regulado.