Motor de diretório de conteúdo

O motor de catálogo é um núcleo de vitrines de jogos e promoções na frente: coleta e normaliza metadados de provedores (RGS), busca/filtros/classificação, aplica regras de disponibilidade por jurisdição e marcas, personaliza a personalização e playsite e dá respostas rápidas via API com SLO previsível.

1) Objetivos e princípios

Leitura rápida: p95 ≤ 100-150 ms para consulta de diretório/pesquisa.
Verdade e frescura: atributos essenciais de relevância garantida (disponibilidade, jackpots, estatais de provedores).
Flexibilidade: coleções de edição e slots promocionais sem lançamentos.
Conformidade: regras de geo/idade/conteúdo, licenças, limitação do jogo responsável.
Multi Tenant/Região: Isolar marcas e respeitar dados residency.
Observabilidade: métricas de qualidade de emissão, A/B, conversão em jogo/aposta.

2) Modelo de domínio (mínimo)

• Game - jogo/produto do provedor.
• Provider - RGS/estúdio.
• Variant - opções de um jogo (volatilidade, linhas, limites, servidor).
• Coleção - Seleção editorial/automática (por exemplo, Novidades, Jackpots).
• Placar - posição fixada/banner/thail na página/slot.
• Capability/Função - atributos do jogo (free spins, buy função, jackpot).
• JurisdictionRule - regras de disponibilidade/restrição.
• Signals - sinais comportamentais/operacionais (popularidade, CTR, revenue).
• Asset - mídia (ícones, pôsteres, vídeo demo) com opções para dispositivos/densidades.

As chaves são 'game _ id' (estável, sem provider _ game _ id), 'tenant _ id', 'region', 'local'.

3) Ingest e normalização

1. Fonte Adapters (Puleros): integração com RGS/estúdios (diretórios, fichas, RTP, tags).

2. Sanitize & Map: mapping de campos externos em um único dicionário (LCA), validação e dedução.

3. Enrich: localizações, categorias, marcas semânticas, classificações de limite de idade.

4. Modernate: bandeiras de conteúdo (NSFW/símbolos religiosos/temas sensíveis) por mercado.

5. Publish: eventos 'GameUpserted/ProviderStatusChanged' → projeção de catálogo.

Idempotidade: todas as mensagens com 'fonte _ id' + 'versão _ ts'; a repetição é tratada sem efeitos colaterais.
Padrão de evolução: 'schema _ version' em adaptadores + migração de muppers.

4) Esquema normalizado (simplificado)

json
{
"game_id": "g_3f92",
"tenant_id": "brand_eu",
"provider": { "id": "pr_evolution", "name": "Evolution" },
"title": { "en": "Lightning Roulette", "de": "Lightning Roulette" },
"capabilities": ["live","roulette","multiplier","bonus"],
"rtp": 97.3,
"volatility": "high",
"limits": { "min": 0.1, "max": 1000.0, "currency": "EUR" },
"jurisdiction": {
"allowed": ["MT","EE","DE"],
"blocked": ["NL","BE"],
"age_rating": 21
},
"assets": {
"tile": { "1x":"...", "2x":"..." },
"poster": { "web":"...", "mobile":"..." }
},
"tags": ["new","jackpot"],
"release_date": "2025-09-12",
"status": "active",
"variants": [{ "id":"v1","server":"eu-central-1","rtp":97.3 }]
}

5) Pesquisa, filtros, facetas

Índices: título/sinônimo completo, facetas por «provider», «capabilities», «volatility», «rtp _ bucket», «tags».
Filtros: jurisdição/região/idioma/dispositivo/idade, apenas ativos/certificados.
Sinônimos/stemming: mapa de termos personalizados («livretos», «frutas», «bolas»).
Falhas: tolerant search (edit distance ≤1 -2) com limite de comprimento.

6) Classificação: sinais e fórmula

• Freshness (tempo do lançamento).
• Popularity (lançamentos/hora, jogadores únicos).
• Quality (CTR de catálogo para jogo, reter 1/7 dia).
• Business (bustos de marketing, transações, slots).
• Compliance (baixa suave para conteúdo sensível, se necessário).
• Player-fit (compatibilidade perfil/preferência).

score = w1freshness + w2popularity + w3ctr + w4player_fit + w5boost

Os pesos são controlados por configurações/experiências; todos os sinais estão normalizados em [0; 1].

7) Personalização

Memória curta: lançamentos recentes e gêneros, RYW - o usuário vê imediatamente ações recentes.
Longa memória: embeddings de jogos e perfil de jogador (gêneros de jogo/volatilidade/sessão).
Segurança: Personalização nunca viola regras jurisdicionais/etárias.
Fallback: se os sinais são escassos - classificação neutra + coleções de edição.

8) Coleções e promoções

• Auto: regra/consulta (por exemplo, 'capabilities contains' jackpot 'AND release _ data> = NOW () -30d').
• Editorial: lista manual com ordem e prazo.
• Playsites: posições fixadas em páginas (hero, row-1-slot-3), A/B, destino por segmentos/jurisdição.
• Prazos e prioridades: 'starts _ at/ends _ at', prioridade dos conflitos, antes da publicação.

9) Complaens e política de disponibilidade

Geo/jurisdição: listas brancas/negras de países/regiões, verificação de licenças/certificados.
Classificação etária: idade mínima, avisos, ocultação para mercados incompatíveis.
Tema/símbolo: bandeiras de conteúdo sensível por país (religião, álcool etc.).
Jogo responsável: ocultação/rebaixamento para jogadores com limites/time.
Auditoria: Contábil de alterações de disponibilidade com razões.

10) Multi tenante e região multi

Todos os dados estão marcados com «tenant _ id» e «region».
Isolamento: quórum/armazenamento por região; projeções cruzadas são apenas máquinas.
Fairness: quotas de ingest/publicação per tenant para que a marca «barulhenta» não detenha os outros.

11) Circuito arquitetônico

Núcleo de diretório Write (COP): normalização + outbox de eventos transacionado.
Projeções/Read Models (EC): índices de pesquisa, coleções materializadas, contadores de popularidade.

• Edge/CDN para páginas/imagens «frias».
• In-memory cash para consultas quentes (key = filtros + página + tenant + region).
• Ficheflagi: localização de regras de classificação/colecção sem lançamento.

12) API (REST/GraphQL, exemplos)

REST

GET /v1/catalog?tenant=brand_eu&region=EE&locale=ru
&filter=jackpot,true&sort=score_desc&page=1&size=24
→ 200 { items:[...], facets:{...}, as_of:"2025-10-31T12:10:02Z" }

GraphQL (fatia)

graphql query Catalog($tenant:String!,$region:String!,$q:String,$filters:Filters){
catalog(tenant:$tenant, region:$region, q:$q, filters:$filters){
items { gameId title provider { name } score badges assets { tile } }
facets { providers { key,count } capabilities { key,count } }
freshnessMs
}
}

• Devolvam sempre 'as_of/freshnessMs', paging, facetas.
• Para personalização - Marcador de sessão (RYW) sem PII.

13) Sinais e fluxo de dados

Popularidade: Encartes ao iniciar jogos → baquetes de minutos → aparelhos em projeção.
CTR/Conversão: Contadores de cliques/lançamentos em playsites/coleções.
Estados operacionais: health provedores (RGS), jackpots/limites (versões de eventos).
Marketing-bustos: taxas de tempo para jogos/categorias/fornecedores.

14) Observabilidade e SLO

• `catalog_p95_ms`, `catalog_p99_ms`, `error_rate`.
• 'index _ freshness _ ms' (atraso no projeto),' ingest _ lag _ ms '.
• «ctr», «click-to-launch», «coleção _ coverage» (% da emissão das coleções).

• `lift_ctr`, `lift_conversion`, «explore vs exploit» доля.

• % de regras geo/idade corretamente aplicadas, número de blocos/hora.

Alerts: Crescimento de 'ingest _ lag _ ms', queda de CTR em coleções-chave, degradação do provedor (rótulos de emissão).

15) Desempenho e armazenamento em dinheiro

Estratégia: Consultas quentes - dinheiro em 30-120 com chave por filtros; Blocos pessoais - TTL curto (10-30 c) ou sem cachê.
Deficiência por evento 'GameUpserted/AvailabilityChanged/PlacementUpdated'.
Paginação: Cursores estáveis para não «rolar» cartões quando os sinais são atualizados.

16) Trabalhar com mídia

Perfis render: tamanho/densidade para web/mobile/TV.
Otimização: WebP/AVIF, lazy-load, sprite/atlas para telhas.
Segurança de Conteúdo: Digitalização, marcas de água, proibição inline-PII.

17) Testes

Contract/Schema testes para adaptadores e API.
Relevancy tests: kits dourados de solicitação → resultados/ordem esperados.
Personalização: offline AUC/NDCG + online A/B com guerrail métricas (tempo de jogo, depósitos, sinais RG).
Chaos: degradação de provedores, picos de ingest, atrasos de indexação.

18) Playbooks (runbooks)

1. Índice de liga> SLO: parar colecções secundárias, aumentar a prioridade do ingest, simplificar temporariamente a classificação.
2. Provedor vermelho: rebaixar/ocultar seus jogos, levantar coleções alternativas.
3. Erro API - Verificar o dinheiro/backend, ativar temporizações de proteção e reduzir o tamanho das páginas.
4. Disponibilidade incorreta: Reverter a regra mais recente, incluir a lista branca dos mercados críticos e auditar as alterações.
5. Lançamento de classificação: rollout canário (5% → 25% → 50% → 100%), reversão CTR/conversão.

19) Erros típicos

Misturar esquemas externos de provedores com um modelo interno (sem LCA).
A ausência de 'as _ of/freshness' → discussões sobre um diretório «obsoleto».
Personalização que viola as regras jurisdicionais.
Única fórmula «mágica» de classificação sem decomposição de sinais e A/B.
Páginas grandes sem o cachê ou o cursor → p99 «disparam».
Dual-write para índice e OLTP em vez de eventos + projeções.

20) Folha de cheque antes de vender

• Dicionário de campos normalizado e LCA para todos os provedores.
• Idempotent ingest, outbox/inbox, DLQ e redrave.
• Projeções de catálogo e índices de pesquisa com SLO de frescura.
• Classificação com balanças controladas, decomposição de sinais e A/B.
• Regras de Complaens (geo/idade/tema) e auditoria de alterações.
• Multi tenante/região: isolamento de dados, fairness, residency.
• API com 'as _ of', facetas, cursores; dinheiro e deficiência por evento.
• Métricas p95/p99, ingest/indenização, CTR/conversão; Alertas.
• Playbooks incidentes; lançamentos de canarinho e ficheflags.
• Testes de relevância, contratações, caos e personalização.

Conclusão

O motor de catálogo é um «motor de busca + sistema de regra + vitrine» acima do conteúdo do jogo. ACL forte, dados normalizados, projeções para leituras rápidas, sinais de classificação transparentes, personalização com métricas de conservrail e uma complexidade rigorosa transformam o catálogo em uma alavanca de crescimento sustentável e mensurável - sem surpresas na produção e sem compromissos com os reguladores.