Hierarquia dos limites

O limite é um limite de transação formalizado em tempo/volume/valor. Em iGaming e fintechs, os limites são a base de segurança, conformidade regulatória e gerenciamento de riscos. A hierarquia dos limites define a regra mais importante e onde ela é cumprida para evitar o duplo desperdício, excesso de taxas/depósitos, abuso de bónus e violações do jogo responsável.

1) Classificação de limites

Sobre o poder de aplicação

Hard - irresistível (proibir a operação).
Soft - aviso/fricção (capcha, confirmação), escalar para hard quando repetido.

Por natureza

Dinheiro: valor do depósito/taxa/pagamento; limites diurnos/semanais/mensais.
Tempo: duração da sessão, interrupções, refrigeração, temporários.
Quantidades: número de transações, spins, solicitações de API.
Velocidade (rate limits): RPS/concorrência.
Quotas: orçamento de ação por janela (N por dia/semana).
Contextuais: por jogo/provedor/método de pagamento/dispositivo/país.

Por proprietário

Reguladores/marcas (tenante/região)

Sistema (plataforma, proteção de infraestrutura)

Personalizado (self-limits dentro do RG)

2) Medidas e chaves (scoping)

tenant_id · region · license · currency · channel · brand player_id · kyc_tier · rg_state · age game_id · provider_id · product (casino/sports/live)
payment_method · device_fingerprint · ip_asn

Quanto mais precisa for a chave, maior será a prioridade (consulte a hierarquia abaixo).

3) Hierarquia e prioridades (matt especiic wins)

GLOBAL_DEFAULT
< TENANT/BRAND
< REGION/LICENCE
< PRODUCT/PROVIDER/GAME
< CURRENCY/CHANNEL/PAYMENT_METHOD
< PLAYER (KYC/RG)
< SESSION/DEVICE
<REQUEST (idempotency-key operation)

• Um contexto mais estreito se sobrepõe a um contexto amplo: player> region.
• Qualquer deny explícito vence allow.
• Os conflitos soft/hard são resolvidos a favor do hard.
• Com o murge de quotas/janelas, vence o valor mínimo permitido (min-cap).

4) Modelo de dados (simplificado)

sql
CREATE TABLE limits (
id      bigserial primary key,
scope jsonb, -- context keys (tenant, region, player_id,...)
kind     text,     -- bet_amount, deposit_daily, rps_api, payout_single, session_duration type     text,     -- HARD      SOFT      QUOTA     RATE value numeric, -- sum/qty/seconds/ops window_sec int, -- for QUOTA/RATE, else null burst int, -- for RATE token-bucket currency text, -- if applicable reason_code text, -- regulator/product/security valid_from timestamptz,
valid_to   timestamptz,
priority int default 0, -- manual specificity overlide created_by text,
created_at  timestamptz default now()
);

CREATE TABLE limit_counters (
key_hash   text primary key,  -- hash(scope,kinda,window_start)
window_start timestamptz,
consumed numeric, -- money/pcs/sec updated_at timestamptz
);

Idempotidade: Todas as operações carregam 'operation _ id'; O acréscimo do contador é executado uma vez (inbox/outbox ou compare-and-swap).

5) Algoritmo de avaliação (evaluation)

1. Recolher candidatos por 'kind' e cruzar 'scope'.
2. Classificação específica (número de medidas correspondentes) e 'priority'.
3. Parâmetros de Merj: dureza (hard> soft), min-cap, min-window.
4. Verificação de quotas/limite de rate: token-baquete (RATE) + fix/janela deslizante (QUOTA).
5. Решение: `ALLOW | SOFT_WARN | DENY` + `retry_after`/`remaining`.
6. A gravação do rasto é uma auditoria do evento e das métricas.

json
{
"decision":"DENY",
"kind":"deposit_daily",
"remaining":0,
"window_reset_at":"2025-10-31T21:00:00Z",
"matched_limit_id":12345,
"policy":"REGULATORY",
"reason":"DAILY_CAP_REACHED"
}

6) Pontos de aplicação (enforcement pontos)

API Gateway - Segurança da infraestrutura: RATE (RPS), CONCURRENCY, burst.
Serviços de domínio - limites de sentido, depósitos, taxas, pagamentos, sessões.
Os adaptadores de provedor são limites de provedores duplicados/locais (validados antes da chamada).
UX cliente - dicas preventivas (SOFT), «N», temporizadores.

Regra: Descontamos uma única vez a quota/token - onde a operação se torna irreversível (após a reserva da carteira/etapa autenticada valida).

7) Limites de dinheiro: depósito/taxa/pagamento

Per currency: Guarde os limites na moeda de transação, em vez de FX voar.
Min/Max: `min_bet`, `max_bet`, `max_payout_single`.
As janelas são 'deposit _ daily/weekly/monthly' com limites fixos (por exemplo, no timeson da licença).
Composição: intervalo permitido final = interseção (regional ∩ marca ∩ personalizado).

8) Jogo responsável (RG)

Self-limits (o jogador definiu ele mesmo) é sempre mais rígido do que marcas.
Restrições de tempo: 'sessions _ duration', 'cool _ off', 'self _ exclusion'.
Escalação: excesso do limite soft → aviso, repetição → hard (dentro da janela).
Auditoria: Cada alteração de RG é captada de forma indevida (quem/quando/porquê).

9) Rate limit vs Quota: quando que

Rate limit (tocen-bucket/leaky): proteção contra picos; aplicar em gateway/adaptadores.
Cota (fixed/sliding window): gerencia o orçamento total de ações/dinheiro; aplicar no domínio (deposit _ daily, bet _ count _ hourly).
Muitas vezes são usados juntos: «RATE» (picos instantâneos) + «QUOTA» (orçamento diário).

10) Multi tenante e região multi

Os limites contêm sempre «tenant _ id» e «region/licence».
Residency: Contadores e armazenamento - na região «doméstica».
Fairness: divida os pulos RATE/COTA per tenant para evitar que o «barulhento» abale o SLO dos outros.

11) Idempotidade e consistência

Comandos com 'operation _ id'; a repetição não deve aumentar 'consumed'.
Para dinheiro - strict path: reserva de carteira e incorporador counters em uma transação/saga (TCC).
Para RATE - use os encartes/armazéns atômicos da janela atual.

12) Observabilidade

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• 'cota _ remaining _ percent' para as vistas principais,
• `rate_throttled`, `burst_dropped`,
• `rg_self_limit_hits`, `regulatory_hits`.

Логи/трейсинг: `matched_limit_id`, `scope_hash`, `operation_id`, `window_start/reset`, `remaining`.

Alerts: crescimento de 'DENY '/' 429' além do limite, frequente realização de capas regulatórias, 'hot key' por jogador/dispositivo.

13) Versionização e auditoria

Cada regra é s 'valid _ from/valid _ to', 'created _ by', 'reason _ código'.
События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.
Guarde a «imagem» das regras ativas para reproduzir soluções históricas (dispute-ready).

14) Testes

Contracto testes: esquema e merj especificidades/prioridades.
Property-based: «se», «deny vence allow», «min-cap».
Golden cases: conjunto de conflitos de referência (região tenante vs, marca RG vs).
Chaos: picos de consulta (RATE), corridas de contagem, repetição de comandos (idempotação).
E2E: jogos de limites nas folhas de cheque do regulador (depósito/semana/mês).

15) Playbooks

1. Tempestade 429/throttling em gateway

Reduzir concurrency, aumentar o token-baquete temporariamente, incluir priorização de vias críticas, analisar fontes (ASN/IP).

2. Falhas em massa no limite regulatório

Verificar o horário das janelas e o timeson; prolongar soft-UX (explicações), notificar a complacência.

3. Desistências falsas por causa de corridas

Ativar a serialização com a chave 'player _ id/kind', ir para CAS/Dedup por 'operation _ id'.

4. Divergência com o limite de abastecimento

Sincronizar min/max per game, adicionar pré-validação ao adaptador, rebaixar temporariamente o catálogo/playsite do jogo.

16) Erros típicos

A falta de hierarquia → «arrastar a corda» entre as regras.
Cálculo de limites em UI sem validação de servidor.
Trocar quotas com limites de rate (e vice-versa).
Ignorar moedas/passos em limites monetários (CLP/JPY).
Não há idempotidade para duplicar a quota.
Um único pool de RATE em todos os tenentes → um problema de shayring.
Falta de auditoria → não é possível explicar a falha.

17) Receitas rápidas

Recepção da aposta: 'max _ bet' = min (região, jogo, provedor, RG personalizado); RATE em '/bets. place '= 20 rps/player, QUOTA = 500 apostas/dia.
Depósitos: 'deposit _ daily/monthly' + 'deposit _ single'; pré-validar os limites PSP.
Sessões: 'sessions _ duration' hard + lembretes a cada N minutos (soft).
Proteção API: RATE global para chave 'ip _ asn' e 'tenant _ id'; janelas de canhão para lançamentos.

18) Folha de cheque antes de vender

• A hierarquia de especificidade e a política de merja foram detectadas (se você quiser que você tenha uma política de merja, deny> allow).
• Modelo de dados com 'scope', 'kind',' tipo ', janelas, divisas e prioridades.
• Pontos de aplicação: gateway (RATE), domínio (COTA/dinheiro), adaptadores (provedores).
• Idempotidade ('operation _ id') e serialização por chave; Contadores de atómona.
• Observabilidade: métricas de soluções, lagoas de janelas, alertas; traçado com 'matched _ limit _ id'.
• Versionização e auditoria imutável de alterações e operações.
• Pacote de teste: contract/property/golden/chaos/E2E.
• O multi-tenante fairness e o data residency foram respeitados.
• UX para limites SOFT: mensagens compreensíveis, 'remaining/retry _ after'.
• Os playbooks de incidentes estão alinhados com compliance e suporte.

Conclusão

A hierarquia dos limites é um sistema de decisão, não um conjunto de números divididos. Especificação clara e ordem de prioridade, modelo de dados unificado, pontos de aplicação corretos, idempotidade e observabilidade transformam os limites em um circuito de segurança e conformidade confiável que é escalado por tenentes, regiões e produtos - e não impede o crescimento.