Torrent Gear

Módulo de torneios e missões: eventos, classificações, prêmios

1) Objetivos de negócios e tipos de ativos

Metas: aumento da retenção (D1/D7), ARPPU, aumento da profundidade das sessões, promoção de novos jogos e mercados.

Formatos:

Torneios: Pontos/Ganhos/Multiplicadores, Springs (30-60 min), diurnos, sazonais.
Missões/buscas: sequências de tarefas (jogue N spin, ganhe X, experimente Y Provedor), com progressos e prêmios de fase.
Liderbords: global, mercados/jogos/apostas, privados (amigos/VIP).
Jackpots/classificações dos estúdios, «top provedores da semana», «caça ao multiplicador».

KPI: Participação ≥ 12% a 25% do público ativo, renda de 10% a 20%, queixas <0. 5% dos participantes, prémio ≤ plano.

2) Arquitetura e fluxo de dados

Componentes

1. Events Gateway → a recepção de eventos de jogos (spin, bet, win, round _ end) do game-gateway/provedores.

2. Rulas Engine → joga eventos para as regras de torneios/missões, atribuindo pontos (idempotent).

3. O Líder Service → agregando óculos, armazenando tops/cortes, suportando triagem e ty breaks.

4. O Progress Service (missões) → o status de tarefas/etapas, a emissão de prêmios intermediários.

5. Rewards Service → pagamento em dinheiro e seguro (por meio de carteira: cash/bônus/fs/pontos).

6. Admin/Studio UI → criação, planejamento, economia, simulações.

7. Realtime/WS → publicando atualizações de liderbord, progresso, notificações.

8. Anti-Abuse → limites, sinais de risco, integração com antifrode/bot gestor.

9. Armazenamento/Cachê → KV/Redis para tops quentes, OLTP para factos, DWH para analistas.

Fluxo (e2e)

`game_event → gateway → rules_match → points → leaderboard_update → (progress_update) → notify → rewards_at_close → wallet_postings`

3) Modelo de evento (mínimo de campos)

json
{
"event_id": "e_9f2",  "ts": "2025-10-23T17:41:26Z",  "user_id": "u_123",  "market": "DE",  "brand": "X",  "game": {"id":"g_77", "provider":"PragmaticPlay", "type":"slot"},  "bet": {"amount_minor": 100, "currency":"EUR"},  "win": {"amount_minor": 250, "multiplier":2. 5},  "round": {"id":"r_abc","status":"ended"},  "device": {"platform":"mobile","asn":"mno"},  "trace_id": "t_…"
}

Transporte - Kafka/HTTP, processamento idempotent (dedupe por 'event _ id'), assinatura do provedor/gateway de jogos (HMAC).

4) Regras de torneios e construção de tarefas

Padrão declaratório (por exemplo, YAML):

yaml id: t_october_sprint window: {start: 2025-10-25T18:00Z, end: 2025-10-25T19:00Z, tz: Europe/Kyiv}
scope:
markets: [DE, SE]
providers: [PragmaticPlay, Hacksaw]
scoring:
formula: "points = min(win. amount/bet. amount, 50) 100" # por multiplicador min _ bet _ menor: 50 eligíveis _ games: ["g _"]
leaderboard:
tipo: «best _ n _ rounds' # somamos os melhores N das rodadas n: 20 tiebreaker: [» highest _ single _ multiplier «», earliest _ finish _ ts']
rewards:
pool: {currency: EUR, total_minor: 1000000}
distribuição: «ladder» # escada, top 100 anti _ abuse:
min_round_duration_ms: 800 max_rps_per_user: 0. 5 exclude_asn_categories: ["hosting", "proxy"]

Missões (DSL):

yaml mission_id: m_halloween steps:
- id: s1 goal: {type: "spin_count", game_type: "slot", count: 50}
reward: {type: "freespins", value: 10, game: "g_66"}
- id: s2 goal: {type: "win_multiplier", min: 10}
reward: {type:"bonus", amount_minor: 500}
completion_reward: {type: "points", amount: 1000}

5) Classificações e algoritmos de contagem

Modelos básicos

Soma de pontos: linear/logarítmico/capt por rodada.

Melhor N round: reduz «pay-to-grind», mantém a dinâmica «sprint».

Multiplicador máximo (xWin): raciona moedas e apostas.

MMR/sistema de classificação: ELO-semelhante para tabelas PvP/competição amigável.

Ty breaks

1. 'highest _ single _ multiplier' → 2) 'fewest _ rounds' → 3)' earliest _ finish _ ts' → 4) 'user _ id' lexicograficamente (fixado nas regras).

Desempenho

Guarde o top K (por exemplo, 10k) no Redis Sorted Set 'ZADD key score member'.

Para «os melhores rounds N»: guarde o min-heap dos melhores N por usuário e valor, atualize «para trás».

Periodicamente snapshot (a cada 30-60 s) em OLTP/objeto.

6) Prêmios e pagamentos

Tipos de prémios: cash/bônus/free spins/pontos/itens/bilhetes.

Regras:

Emissão somente após a finalização (janela de recurso 5-10 min).
Todos os pagamentos são feitos através do Rewards Service → Wallet (ledger): duplo-entry, idempotação por 'reward _ id'.
Para os estágios intermediários das missões, a emissão de prêmios «suaves» (FS/pontos) e cash após a conclusão da cadeia.
Jogo responsável/CUS: ao bloquear a conta, reter/congelar o prémio até a verificação.

Esquemas de distribuição:

Fixed ladder: degraus pré-definidos (1º 30%, 2º 20%,...).
Proportional: fatia do pool por ponto, mas de cap para lugar.
Ted-based: as missões oferecem «bilhetes», uma partida de bilhetes (RNG transparente).

7) Anti-Abuse, honestidade e complacência

Filtros de eligibilidade: min/duração da rodada, exclusão de «0-bet», re-fissuras repetidas, «micro-apostas» na linha de montagem.

Sinais bot: headless-UA, frequência anormal, RPS anormalmente estável, proxy-ASN → challengs ocultos/congelamento de óculos.

Dedução/idempotação: eventos por 'event _ id', acumulação por 'score _ id'.

Check trail: fotos de liderbord, seed RNG (para ticket), versão de regras, hash de cálculo.

Legal: regras/restrições de mercado, idade, auto-exclusão.

8) Economia de torneios

Budget: borda superior do pool + dinâmica «safety valve» (redução dos bónus intermediários quando superaquecido).

Elasticidade: transferência de prémios em pontos/FS em vez de cash para reter margens.

Taxas de retorno: prémios/receitas do segmento de jogos de torneio; Meta 8-15%.

Simulador no Adminc: detecção de eventos históricos → previsão de pagamento/participação.

9) Contratos API (simplificado)

Obter torneios/missões ativos

http
GET /v1/contests? market=DE&brand=X
→ 200 [{"id":"t_october_sprint","start":"…","end":"…","type":"xwin","status":"live"}]

Evento de jogo (ingest)

http
POST /v1/events
{"event_id":"e_9f2", "...": "..."}
→ 202 {"accepted":true}

Liderbord (top K e posição do usuário)

http
GET /v1/leaderboards/t_october_sprint? top=100&me=u_123
→ 200 {"top":[{"pos":1,"user":"u_9","score":18400},...],    "me":{"pos":342,"score":5600,"delta":+200}}

Progresso da missão e recompensa

http
GET /v1/missions/m_halloween/progress? user=u_123
→ 200 {"steps":[{"id":"s1","done":true},{"id":"s2","done":false}],"reward_ready":true}

POST /v1/rewards/claim
{"context":"mission","id":"m_halloween","step":"s1"}
→ 201 {"status":"granted","reward_id":"rw_77"}

10) Armazenamento e zoom

Caminho quente: Redis (Sorted Sets/Hash) para top e progresso; TTL para chaves «ruidosas», charding por «contest _ id».

Verdade: OLTP (Postgres/MySQL) - factos de pontos/progresso/pagamento (BPM).

Filas: Kafka - fluxo de eventos; Grupos Consumer por região/marca.

Cachês: TTL curto 1-5 s; stale-while-revalidate para tops públicos (via CDN).

WebSocket: um cluster/pool separado sob realtime, mensagens de envio e rate-limit.

11) Observabilidade e controle de qualidade

SLI/SLO:

`leaderboard_update_latency_p95 ≤ 250мс`
`events_ingest_success ≥ 99. 9%`
`rewards_grant_success ≥ 99. 9%`
`ws_push_rtt_p95 ≤ 120мс`
queixas de injustiça <0. 5% dos participantes.

Métricas:

rate eventos/participantes, jogadores únicos, distribuição em apostas/jogos, multiplicador médio; 'grant _ errors', 'dedupe _ hits'.
Trailers: ingest → rulas → score → LB update → reward; tags 'contest _ id', 'rule _ id'.
Logi: JSON com 'trace _ id', proibição PII; WORM para auditoria.

12) Incidentes e runbook 'e (reduzido)

A. Atraso do liderbord (lag> 2s)

Ações: aumentar os consumidores de Kafka, reduzir a «chave quente» de partição (repartition), incluir batching update.

Temporal: congelar animações realtime, exibir «£1-2s atrasos».

B. Erros na emissão de prêmios

Acções: parar os novos 'grant', encurtar com o snapshot, reaproveitar 'grant' idempotadamente; Status-update no lobby.

C. Aumento de abyuz (proxy ASN)

Ações: Reforçar a eligibilidade, incluir um challenge invisível, ignorar temporariamente os pontos com sessões duvidosas, pós-verificação.

13) UX e localização

Tempo real: indicador «live», delta de pontos suaves, posição e distância para o próximo lugar.

Regras transparentes: acesso à fórmula/tie breaks/restrições.

«5 minutos», «estás no top 50», «está disponível».

Texto/texto legal: mercados, fusos horários (Europa/Kyiv e localização dos participantes).

14) Segurança e privacidade

Pseudônimos de jogadores em top públicos; ocultar o PII padrão.

Assinaturas de webhooks/eventos, mTLS; protecção contra «cash-pozon» no edge.

Rate-limit API, protecção contra dinheiro-basting, controle 'idempotency _ key'.

GDPR: prazo de armazenamento de eventos, direito de remoção (anonimato) sem quebra de auditoria.

15) Testes e simulações

Uma réplica de eventos históricos para validar as regras e a economia.

Cargas: bursts 30-120 s antes do lançamento; soak 2-4 h.

Property-based: invariantes («prémios concedidos ≤ orçamento», «tai-break determinado»).

A/B: diferentes fórmulas de óculos, profundidade da escada, formato das missões.

16) Folha de cheque de produção pronta

Regras declaratórias (versões, assinaturas), simulador de economia.
Idempotidade: 'event _ id', 'score _ id', 'reward _ id'; Inbox/Outbox.
Os ty-breaks são fixos em regras, determinismo de triagem.
Liderbords: Top K em Redis + slots; anti-tempestade (jitter, coalescing).
Anti-abuse: elisibilidade, bots/ASN, limites velocity.
Rewards → Wallet via duplo-entry; Cheque KYC antes do cash.
Observabilidade: SLI/SLO, dashboards, alertas; Auditoria WORM.
DR./Failover: multi-AZ, bacapes/restore, «freeze & finalize».
Localização, licenças, regras públicas e consent.
Runbook 'e em lag/erros grant/saliência de bots, modelos de comunicação.

Currículos

O pod de sucesso de torneios e missões é um pneu de eventos + regras determinadas + liderbords rápidos + pagamentos seguros. Adicione tie breaks rigorosos, anti-abuse, simulador de economia e observação SLO, mantenha todas as operações idepotentes e audíveis - e você terá uma ferramenta que cria envolvimento e receita sem disputas com jogadores, reguladores e equipe de apoio.