Quando a roleta chegou a todo mundo
A maior parte do que deu errado aconteceu depois que a roleta já funcionava. Os lançamentos pequenos escondiam problemas que só apareceram em escala total. Eu era o dono do produto, então esta lista é minha. Ninguém nela foi descuidado. Cada incidente foi um sistema com um limite que ninguém tinha encostado ainda, e uma etapa de configuração que passou por um par de olhos só.
Abrir a roleta para todos sobrecarregou a plataforma de recompensas. A Parte 1 conta o dia em si. Quando a base inteira entrou, a plataforma precisou criar muitas roletas no mesmo instante, e a entrega oscilou. Não tenho nas minhas notas uma linha do tempo limpa daquele dia, e não vou inventar uma. O que tenho é o que mudamos. As roletas passaram a sair em lotes com alguns minutos de intervalo, em ordem de importância, de modo que as roletas dos jogadores mais valiosos são as primeiras a chegar se algo ficar lento. E avisamos a equipe da plataforma antes de todo lançamento grande, para que eles esperem o pico.
Depois um bônus acabou, e a central de atendimento sentiu primeiro. Cada fatia de prêmio da roleta entrega um bônus criado na plataforma de apostas, e todo bônus tem um limite de giros grátis como salvaguarda. Quando subimos as roletas antigas para 70% da base, um desses bônus foi consumido rápido. O segundo mais usado tinha gasto cerca de 20% do limite, e outros dois cerca de 10% cada. Quem ganhou esse prêmio não conseguia usá-lo no site, e ligou para a central.
Um bônus no limite enquanto os outros estavam longe disso. O mesmo desenho explica a causa.
A causa foi uma configuração minha: duas fatias dividiam o mesmo bônus. Na roleta que falhou, duas fatias diferentes pagavam 10 giros grátis, cada uma com 41,24% de chance, e as duas tiravam do mesmo bônus. Ou seja, cerca de 82% de todos os giros daquela roleta consumiam um único estoque. O limite tinha sido dimensionado como se a carga estivesse espalhada pela roleta inteira. Não estava.
A correção foi um bônus por fatia, dimensionado para 30 dias. Nas três roletas com mais pressão sobre um único resultado, passamos de duas fatias do menor prêmio para quatro, cada uma com seu próprio bônus. E passamos a calcular cada limite para durar pelo menos 30 dias no volume esperado, em vez de escolher um número redondo. A operação criou na hora um bônus novo para os jogadores que reclamavam, outro para substituir o bônus esgotado na roleta, e depois renovou os bônus duas vezes, subindo o limite a cada vez. Essa força-tarefa gastou seu tempo num trabalho que uma configuração inicial melhor teria evitado. Conto esse tempo como parte do custo.
A central foi a primeira a sentir e a primeira a nos avisar. As chamadas subiram, e os chamados só caíram depois que os bônus foram renovados e as segmentações corrigidas. Tento manter a história honesta: um relatório semanal do começo de outubro registrou que o volume de chamadas não tinha saído muito da média dos três meses anteriores, embora dentro do time parecesse bem pior. Então parte da dor era real e parte era o ruído de uma semana de lançamento. De qualquer forma, a central precisava de trabalho estrutural, não só de um conserto rápido.
A auditoria das segmentações achou uma segunda causa. Alguns jogadores não recebiam roleta nenhuma. Quando conferimos, 5 das 17 segmentações estavam erradas. Quatro foram achadas e corrigidas numa segunda-feira e a última na terça. Mais ou menos na mesma época, jogadores reclamaram que tinham caído do nível 7 para o nível 0. A marcação que a plataforma usava para caçadores de bônus não era confiável e tinha empurrado gente para fora do nível. Tiramos esse bloqueio. Dali em diante, as roletas que pagam só vão para quem teve turnover nos últimos 30 dias.
Um botão chamava a plataforma de recompensas a cada carregamento de página. Ele deveria chamar só quando o jogador clicasse. Com a base inteira na roleta, essas chamadas se somaram como carga extra na plataforma. A engenharia moveu a chamada para o clique, e as chamadas do botão à plataforma caíram 95%.
A mesma tela, os mesmos jogadores. A única mudança foi o momento da chamada.
Três cofres num fim de semana
O cofre semanal saiu três vezes num fim de semana por causa de uma única configuração. O Cofre começou na Black Friday e virou um envio semanal, com a mesma regra: um bônus de 10% da receita líquida dos últimos 7 dias do jogador, com rollover de 1x. O primeiro envio semanal foi em 19 de dezembro e teve um erro de mecanismo, que corrigimos no dia 23. Na sexta, 26 de dezembro, enviamos de novo, já com o mecanismo funcionando. Mas o gatilho estava configurado para rodar todo dia às 17h, em vez de às sextas às 11h. Esse foi o erro inteiro. Ele gerou dois cofres extras, um no sábado, dia 27, e outro no domingo, dia 28.
Cinco dias. O envio do dia 23 foi planejado. Os dois extras não foram.
Quem percebeu foi o financeiro, na segunda, e não a gente. O time financeiro viu que o gasto com bônus estava acima do esperado e nos avisou. Inspecionamos a configuração, achamos o gatilho e corrigimos antes das 17h do mesmo dia, ou seja, antes que um quarto envio saísse. Sou grato ao financeiro por isso. O monitoramento do time de risco ainda não estava preparado para esse caso, então não tínhamos alarme próprio.
O que custou, em termos simples. A regra de desenho do cofre semanal é 10% da receita líquida dos 7 dias anteriores. Cada envio extra custou 8,05% (sábado) e 7,44% (domingo) da receita bruta dos 7 dias anteriores. As duas bases não medem a mesma coisa, então leio a comparação como ordem de grandeza, não como conta exata. O ponto se mantém: cada extra foi quase um cofre inteiro. Em números redondos, o fim de semana gastou cerca de três orçamentos de cofre onde havia um planejado.
A sobreposição é o que fez isso ser pior do que parece. Entre os jogadores contados no post mortem, um pouco mais da metade recebeu só um cofre. Perto de um quarto recebeu dois. E mais de um em cada quatro recebeu os três.
Parte dos jogadores por número de cofres recebidos.
Bônus com rollover sobrepostos são mais fáceis de liberar. O rollover pede que o jogador aposte um múltiplo do bônus antes de o dinheiro ser liberado. Quando vários estão ativos ao mesmo tempo, as mesmas apostas contam para todos. Então um jogador com três cofres precisava apostar mais ou menos o que um jogador com um cofre precisava, para liberar o triplo do dinheiro. O custo veio dos bônus criados e da facilidade com que foram liberados.
A análise foi difícil, e isso fez parte do problema. Havia um buraco entre três sistemas. A plataforma de recompensas sabia quantos cofres foram enviados e abertos, e por quem, no ID próprio dela. A plataforma de apostas sabia quando cada bônus foi criado, resgatado e cumprido, num ID diferente. A ferramenta de análise do time de dados não tinha nenhum dos dois. Além disso, tínhamos enviado o mesmo código de bônus todos os dias. Um jogador que abriu os cofres dos dias 23, 26, 27 e 28 tinha quatro bônus que mostravam todos a data de criação do dia 28. Para separá-los seria preciso recalcular a receita de 7 dias de cada dia. Dá para fazer com tempo, mas não rápido.
A sobreposição do dia 23 foi decisão minha, e acho que estava errada. Ela foi intencional. Eu defendi que o cofre enviado no dia 23 vencesse na sexta, dia 26. A central de atendimento exigiu que durasse 7 dias, como tínhamos prometido aos jogadores. No fim fizemos como a central pediu. Olhando para trás, a promessa era a coisa certa a proteger, mas dois cofres um em cima do outro deveriam ter sido evitados no desenho, não aceitos.
O que mudamos. O post mortem listou os aprendizados, e eu os resumi.
- Uma segunda pessoa, nunca a que montou, revisa toda configuração antes de ela ir ao ar. Um cofre tem muitos detalhes dentro da plataforma de recompensas, e quem montou é a pior pessoa para achar o erro. O CRM era o time óbvio para isso.
- Um bônus diferente para cada envio. Criar um bônus novo por semana é um custo pequeno e dá dados limpos por semana.
- Data de validade fixa nos bônus semanais, e termos de uso que digam isso, para que um cofre aberto no dia 6 não se sobreponha ao próximo.
- Nenhuma sobreposição de cofres, mesmo quando a pressão para isso é razoável.
- Dados para acompanhar a conclusão: precisamos ver quantos bônus com rollover foram cumpridos e pagos, e não só quantos foram criados.
- Dar ao time de risco o que ele precisa para pegar um caso assim no sábado, não na segunda.
Uma fila que travou em março
Em março de 2026 a plataforma nos avisou que as atividades por horário estavam atrasadas. O serviço que roda atividades em hora marcada tinha acumulado uma fila. Atividades e condições de entrada do ciclo de vida que deveriam disparar numa hora saíam atrasadas, conforme o sistema recuperava o atraso. O time de produto já tinha visto o envio das roletas oscilar no dia anterior. A fila foi totalmente processada na manhã seguinte. A plataforma disse que não conseguiu confirmar uma causa raiz e apontou o que parecia o gatilho.
O gatilho era um campo pesado na segmentação. A plataforma contou 56 atividades que usavam o mesmo campo calculado de turnover dos últimos 30 dias, em vez de um campo nativo mais leve. Todas rodavam por volta das 17h UTC, em dias diferentes da semana. Muitas no mesmo horário, cada uma fazendo uma pergunta cara, formaram a fila. A plataforma pediu que usássemos pelo menos o campo mais leve e que espalhássemos as atividades ao longo do dia.
A investigação achou algo que eu não esperava: o campo estava errado. Trocar pelo campo nativo não era possível do jeito que estava, porque os dois campos não significavam a mesma coisa. O time de produto olhou dentro do campo calculado. Ele somava o turnover de cassino e de apostas esportivas, mas a parte de cassino contava o cassino ao vivo, que tínhamos combinado não incluir, e a parte de esportes usava a média por aposta em vez do total apostado. A média puxava o número para baixo, e continuava sendo o número errado. A pergunta que me fizeram foi se era para ser assim mesmo. A resposta foi que a regra precisava ser alinhada de novo primeiro. A regra nunca tinha sido escrita num lugar só, e é assim que uma definição errada sobrevive.
Nossa resposta teve duas partes. Primeiro, pedir à plataforma que criasse um campo nativo igual à regra que queremos: cassino sem o ao vivo mais o total de esportes. Isso eliminaria a necessidade do cálculo pesado. Segundo, espalhar o horário das atividades para que elas não disparem todas na mesma janela. Operações e produto concordaram que o conceito precisava ser alinhado primeiro e a regra ajustada depois. Saí antes de poder confirmar que o campo novo estava no ar.
Três meses antes, a plataforma teve outro tipo de falha. Em 29 de dezembro a entrega das roletas caiu, o que afetou vários jogadores, e foi restabelecida no dia 30. Cito isso porque é o outro lado da mesma lição. Parte do sistema está fora do nosso controle, então o plano precisa incluir como descobrimos e como explicamos aos jogadores e à central.
O que os casos de atendimento mostraram
Cerca de 60 fichas de casos de setembro e outubro mostraram do que os jogadores reclamavam. Li o conjunto com nomes e dados pessoais já removidos. O motivo mais comum, de longe, era “estou fora da segmentação”: cerca de 13 dos casos com motivo registrado, incluindo vários caçadores de bônus que reclamavam de não receber o que outros recebiam. A conferência era sempre a mesma: passar pelos critérios do nível do jogador, como depósitos em 90 dias, aposta média em esportes e cassino em 7 dias e bônus recebido em 7 dias, e olhar as marcações que o jogador tinha na plataforma.
Os outros casos se repartem em poucos tipos. O jogador não conseguiu resgatar o bônus, resgatou mas não conseguiu usar, nunca recebeu a roleta, foi excluído na plataforma, tentou depois de a promoção acabar, ou viu uma tela que não carregava.
Dos 67 casos do registro, 14 foram fechados e 53 não. São 79% em aberto. Quase sempre a resposta já tinha sido dada e o registro nunca foi fechado. Leio isso como uma falha de processo mais do que 53 problemas sem solução. Mesmo assim, tem um custo real: não dá para medir qual tipo de problema está diminuindo, nem quanto tempo uma correção leva, se nada é fechado com uma resolução.
Saíram duas lições. A conferência de elegibilidade precisa ser rápida e feita por quem atende os jogadores, não pelo time de produto. E todo caso novo deve ser fechado com um tipo de resolução, senão não dá para medir nada depois. As duas estão na lista de regras abaixo.
As regras que ficaram, e o que ainda estava aberto
As regras que o time adotou ou combinou vieram dos incidentes, não de um plano. Cada uma tem um incidente por trás.
Como uma configuração chega à produção hoje. A etapa em vermelho é a que o fim de semana dos cofres acrescentou.
- Uma segunda pessoa revisa toda configuração antes de ela ir ao ar (o primeiro item da lista acima).
- Um bônus para cada fatia de uma roleta, com limite dimensionado para pelo menos 30 dias.
- Um código de bônus novo para cada envio semanal, com data de validade fixa.
- Nunca dois cofres ao mesmo tempo.
- Avisar a plataforma de recompensas antes de um lançamento grande e enviar as roletas em lotes, as mais importantes primeiro.
- As chamadas à plataforma de recompensas acontecem no clique, não no carregamento da página.
- Atividades por horário usam campos leves e são espalhadas ao longo do dia (combinado com a plataforma, não concluído).
- Todo caso de atendimento é fechado com um tipo de resolução, e a conferência de elegibilidade fica com quem atende os jogadores.
- Acompanhar o custo de bônus como parte da receita, todo dia, junto com risco (proposto ao time de risco).
Algumas coisas ainda não estavam resolvidas quando eu saí. Quero dizer isso com clareza.
- O buraco de dados entre a plataforma de recompensas, a plataforma de apostas e a ferramenta de análise. Conseguíamos dizer quantos cofres foram enviados, mas não com limpeza quantos bônus com rollover foram cumpridos.
- O monitoramento do time de risco para o caso do cofre e a visão diária de custo. Não consigo confirmar que algum dos dois estava pronto.
- A regra de turnover por trás do campo pesado. O campo nativo novo foi pedido, mas não confirmado no ar, e as 56 atividades ainda não tinham sido movidas.
- O registro de atendimento. A regra de fechar cada caso foi combinada. O acúmulo de 53 casos abertos não foi limpo no registro.
- A validade fixa e os termos de uso atualizados dos cofres semanais. Não consigo confirmar que foram feitos.
O que eu diria para a próxima pessoa. A maioria desses incidentes veio de um limite que ninguém tinha testado encontrando uma configuração conferida por uma pessoa só. As defesas baratas são simples: um segundo revisor, um bônus por fatia, um código diferente a cada semana, uma regra escrita num lugar só. Eu gostaria de ter colocado todas no lugar antes do primeiro lançamento, e não depois dos incidentes.