Jerarquía de límites

El límite es el límite formalizado de la operación en tiempo/volumen/costo. En iGaming y Fintech, los límites son la base de la seguridad, el cumplimiento de normas y la gestión de riesgos. La jerarquía de límites establece cuál es la regla principal y dónde se ejecuta para evitar el doble gasto, exceso de apuestas/depósitos, abuso de bonificaciones y violaciones del juego responsable.

1) Clasificación de límites

Por fuerza de uso

Hard - insuperable (prohibición de la operación).
Soft - advertencia/fricción (capcha, confirmación), escalamiento a duro cuando se repite.

Por

Efectivo: importe del depósito/tasa/pago; límites diurnos/semanales/mensuales.
Temporal: duración de la sesión, interrupciones, «enfriamiento», tiempos de espera.
Cuantitativo: número de transacciones, giros, solicitudes de API.
Velocidad (rate limits): RPS/competencia.
Cuotas: presupuesto de acción por ventana (N por día/semana).
Contextual: por juego/proveedor/método de pago/dispositivo/país.

Por propietario

Regulador/de marca (tenant/región)

Sistema (plataforma, protección de la infraestructura)

Personalizado (self-limits dentro de RG)

2) Medidas y llaves (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

Cuanto más precisa sea la clave, mayor será la prioridad (consulte la jerarquía a continuación).

3) Jerarquía y prioridades (más vinos específicos)

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

• El contexto más estrecho se superpone al amplio: player> region.
• Cualquier deny explícito gana allow.
• Los conflictos soft/hard se resuelven a favor de la mano dura.
• Con el merje de cuotas/ventanas, gana el valor mínimo permitido (min-cap).

4) Modelo de datos (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
);

Idempotencia: todas las operaciones llevan 'operation _ id'; el incremento del contador se realiza una vez (inbox/outbox o compare-and-swap por versión).

5) Algoritmo de evaluación (evaluación)

1. Recogida de candidatos por 'kind' y cruce de' scope '.
2. Clasificación por especificidad (número de medidas coincidentes) y 'priority'.
3. Parámetro Merge: rigidez (hard> soft), min-cap, min-window.
4. Verificación de cuota/límite de velocidad: token-baket (TASA) + fix/ventana deslizante (QUOTA).
5. Решение: `ALLOW | SOFT_WARN | DENY` + `retry_after`/`remaining`.
6. Registro de seguimiento: auditoría de eventos y 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) Puntos de aplicación (puntos de enforcement)

API Gateway - Protección de infraestructura: RATE (RPS), CONCURRENCY, burst.
Servicios de dominio - límites semánticos: depósitos, apuestas, pagos, sesiones.
Adaptadores de proveedor: los límites duplicados/locales de los proveedores (validar antes de la llamada).
UX cliente - Consejos preventivos (SOFT), «sobran N», temporizadores.

Regla: cancelar una cuota/tokens una vez - donde la operación se convierte en irreversible (después de reservar el monedero/paso autenticado válido).

7) Límites monetarios: depósito/tasa/pago

Por currency: guarda los límites en la divisa de la operación, no a través de FX «sobre la marcha».
Min/Max: `min_bet`, `max_bet`, `max_payout_single`.
Ventanas: 'deposit _ daily/weekly/monthly' con límites fijos (por ejemplo, en el tiempo de licencia).
Composición: rango total permitido = intersección (regional ∩ de marca ∩ personalizado).

8) Juego responsable (RG)

Los self-limits (el jugador se ha fijado) son siempre más duros que los de marca.
Limitaciones de tiempo: 'session _ duration', 'cool _ off', 'self _ exclusion'.
Escalamiento: superando el límite soft → advertencia, repetición → hard (dentro de la ventana).
Auditoría: cada cambio de RG se registra de forma invisible (quién/cuándo/por qué).

9) Rate limit vs Quota: cuándo qué

Límite de velocidad (token-bucket/leaky): protección contra ráfagas; aplicar en gateway/adaptadores.
Quota (ventana fija/deslizante): administrar el presupuesto total de acciones/dinero; aplicar en un dominio (deposit_daily, bet_count_hourly).
A menudo se utilizan juntos: 'RATE' (picos instantáneos) + 'QUOTA' (presupuesto diario).

10) Multi-tenant y multi-región

Los límites siempre contienen 'tenant _ id' y 'region/licence'.
Residencia: contadores y almacenamiento - en una región «doméstica».
Fairness: separe los grupos RATE/QUOTA per tenant para que el «ruidoso» no interrumpa el SLO de otros.

11) Idempotencia y consistencia

Comandos con 'operation _ id'; la repetición no debe aumentar 'consumed'.
Para dinero - strict path: reserva de billetera e incrementos de counters en una sola transacción/saga (TCC).
Para RATE - Utilice los incrementos atómicos/almacenes de la ventana actual.

12) Observabilidad

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• 'quota _ remaining _ percent' por especies principales,
• `rate_throttled`, `burst_dropped`,
• `rg_self_limit_hits`, `regulatory_hits`.

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

Alertas: crecimiento de 'DENY '/' 429' más allá del umbral, logro frecuente de las gotas regulatorias, 'hot key' por jugador/dispositivo.

13) Versificación y auditoría

Cada regla es con 'valid _ from/valid _ to', 'created _ by', 'reason _ code'.
События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.
Almacene una «instantánea» de las reglas activas para reproducir soluciones históricas (dispute-ready).

14) Pruebas

Pruebas de contrato: esquema y parámetro de especificidades/prioridades.
Property-based: «más vinos especiales», «deny gana allow», «min-cap».
Casos de oro: conjunto de conflictos de referencia (tenant vs región, RG vs marca).
Chaos: ráfagas de solicitudes (RATE), carreras por contadores, repetición de equipos (idempotencia).
E2E: partidos de límites en las listas de cheques del regulador (depósito/semana/mes).

15) Playbucks

1. Tormenta 429/throttling en gateway

Reducir la concurrencia, aumentar temporalmente el token baket, activar la priorización de rutas críticas, analizar fuentes (ASN/IP).

2. Fallos masivos en el límite regulatorio

Comprobar el horario de las ventanas y el tiempo de espera; prolongar soft-UX (explicaciones), notificar el cumplimiento.

3. Falsos negativos positivos debido a las carreras

Habilitar la serialización por clave 'player _ id/kind', ir a CAS/dedoop por' operation _ id '.

4. Discrepancia con el límite de proveedores

Sincronizar min/max por juego, agregar una pre-validación al adaptador, bajar temporalmente el directorio/playsment del juego.

16) Errores típicos

La falta de jerarquía → «arrastrar la cuerda» entre las reglas.
Cálculo de límites en IU sin validación de servidor.
Sustitución de cuotas por límites de rate (y viceversa).
Ignorar las monedas/pasos en los límites monetarios (CLP/JPY).
No hay idempotencia → doble quita de cuota.
Una sola agrupación de RATE en todos los tenantes → problemas de shearing.
La falta de auditoría → es imposible explicar el rechazo.

17) Recetas rápidas

Aceptación de apuestas: 'max _ bet' = min (región, juego, proveedor, RG personalizado); RATE en '/bets. place '= 20 rps/player, QUOTA = 500 apuestas/día.
Depósitos: 'depósito _ daily/monthly' + 'depósito _ single'; validar los límites PSP.
Sesiones: 'session _ duration' hard + recordatorios cada N minutos (soft).
Protección API: RATE global por claves 'ip _ asn' y' tenant _ id '; ventanas canarias para lanzamientos.

18) Lista de verificación antes de la venta

• Se ha establecido la jerarquía de especificidad y la política del merge (más vinos específicos, deny> allow).
• Modelo de datos con 'scope', 'kind',' type ', ventanas, monedas y prioridades.
• Puntos de aplicación: gateway (RATE), dominio (QUOTA/monetario), adaptadores (proveedor).
• Idempotencia ('operation _ id') y serialización por claves; los contadores son atómicos.
• Observabilidad: métricas de soluciones, lagunas de ventanas, alertas; seguimiento con 'matched _ limit _ id'.
• Versionar y auditar sin cambios los cambios y los positivos.
• Paquete de prueba: contract/property/golden/chaos/E2E.
• Se cumplen la residencia de fairness y data multi-tenant.
• UX para límites SOFT: mensajes comprensibles, 'remaining/retry _ after'.
• Los playbucks de incidentes están alineados con el cumplimiento y el soporte.

Conclusión

La jerarquía de límites es un sistema de toma de decisiones, no un conjunto de números dispares. La especificidad clara y el orden de prioridades, el modelo único de datos, los puntos de aplicación correctos, la idempotencia y la observabilidad convierten los límites en un circuito fiable de seguridad y conformidad que escala por tenantes, regiones y productos, y no interfiere con el crecimiento.