限制层次结构

限制是交易在时间/范围/成本上的形式化限制。在iGaming和fintech中，限制是安全性，法规合规性和风险管理的基础。限制层次结构指定谁的规则更重要，在哪里执行，以防止双重支出，超额投注/存款，滥用奖金和违反负责任的游戏。

1）限制分类

关于使用的强度

硬是不可抗拒的（禁止操作）。
Soft-警告/摩擦（kapcha,确认）,在重播时升级为硬。

通过自然

现金：存款/利率/付款金额；每天/每周/每月限额。
时间：会话时间，休息时间，"冷却"，超时。
定量：事务数、自旋数、API请求数。
速度（比例限制）：RPS/竞争力。
配额：每窗口行动预算（每天/每周N）。
上下文：通过游戏/提供商/支付方法/设备/国家/地区。

通过所有者

监管/品牌（tenant/region）

系统（平台、基础架构保护）

定制（RG内的自我限制）

2）测量和密钥（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

键越准确，优先级越高（请参见下面的层次结构）。

3）层次结构和优先级（最特殊的胜利）

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

• 较窄的上下文覆盖宽：player> region。
• 任何明显的deny都会赢得allow。
• 软/硬冲突得到解决，有利于硬冲突。
• 在配额/窗口冻结中，将击败最小有效值（min-cap）。

4）数据模型（简化）

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
);

相等性：所有操作均带有"operation_id"；计数器内部化一次执行（inbox/outbox或按版本计算和交换）。

5）评估算法（评估）

1.通过"kind"和交叉点"scope"收集候选人。
2.按特异性（并发维数）和"优先"排名。
3.参数变量：刚度（hard> soft）、min-cap、min-window。
4.配额验证/限制：令牌罐（RATE）+fix/滑动窗口 （QUOTA）。

5.Решение: `ALLOW | SOFT_WARN | DENY` + `retry_after`/`remaining`.

6.跟踪记录：事件审核和指标。

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）应用点（执行点）

Gateway API-基础架构保护：RATE （RPS）, CONCURRENCY, burst。
域名服务-语义限制：存款，利率，付款，会话。
提供者适配器-提供者的重复/本地限制（在呼叫前验证）。
客户端UX是预防性提示（SOFT），"保留N"，计时器。

规则：我们一次注销配额/代币-在操作变得不可逆的地方（在预留钱包/验证的认证步骤之后）。

7）现金限额： 存款/利率/付款

按货币计价：以交易货币而不是通过FX"即时"持有限额。

Min/Max: `min_bet`, `max_bet`, `max_payout_single`.

窗口：具有固定边界的"deposit_daily/weekly/monthly"（例如许可证时间段）。
组成：最终允许范围=相交（区域∩品牌∩自定义）。

8）负责任的游戏（RG）

自我限制（玩家自己设置）始终比品牌更严格。
时间限制："session_duration"，"cool_off"，"self_exclusion"。
升级：超出软限制→警告、重播→硬件（在窗口内）。
审计：每个RG更改都是不可修改的（谁/何时/为什么）。

9）利率极限vs Quota： 什么时候

Rate limit （token-bucket/leaky）：防爆；在网关/适配器上应用。
Quota（固定/滑动窗口）：管理Activity/Money总预算；在域（deposit_daily、bet_count_hourly)中应用。
通常一起使用："RATE"（即时峰值）+"QUOTA"（每日预算）。

10）多特南特和多区域

限制始终包含"tenant_id"和"region/licence"。
住宅：计数器和存储-在"家庭"地区。
公平：拆分RATE/COTA per tenant池,以便"嘈杂"不会破坏他人的SLO。

11）相同性和一致性

带有"operation_id"的命令；重播不应增加"消费"。
对于金钱-strict path：一个交易/传奇（TCC）中的钱包储备和计数器嵌入。
对于RATE,使用原子嵌合/仓库当前窗口。

12）可观察性

• `limit_eval_p95_ms`, `decision_rate{ALLOW,DENY,SOFT}`,
• 'cota_remaining_percent'按主要种类排列，
• `rate_throttled`, `burst_dropped`,
• `rg_self_limit_hits`, `regulatory_hits`.

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

Alerts： "DENY"/"429"的增长超过阈值,经常达到调节帽,"热键"通过玩家/设备。

13）验证和审计

每个规则均带有"valid_from/valid_to"，"created_by"，"reason_code"。

События: `LimitCreated/Updated/Deleted`, `LimitHit`, `LimitDenied`.

存储活动规则的"快照"以播放历史决策（dispute-ready）。

14）测试

合同测试：特定/优先级图和计划。
基于property："most specific wins"，"deny wins allow"，"min-cap"。
Golden cases：一组参考冲突（tenant vs region, RG vs品牌）。
混乱：查询激增（RATE），计数器比赛，车队重播（相等）。
E2E：限制监管机构支票清单的对决（存款/每周/每月）。

15）花花公子

1.风暴在网关上429/throttling

减少串联，暂时增加令牌罐，包括关键路径优先级，源分析（ASN/IP）。

2.监管限制下的大规模豁免

检查窗口的时间表和时间段；延长soft-UX（解释），通知合规性。

3.由于比赛而导致的错误正面拒绝

在"player_id/kind"键上启用序列化,然后通过"operation_id"转到CAS/dedup。

4.与提供商限制的差异

同步min/max per游戏,向适配器添加预验证,暂时降级游戏目录/播放。

16）典型错误

缺乏层次结构→规则之间的"拔河"。
在UI中计算极限而无需服务器验证。
用rate限额替换配额（反之亦然）。
在货币限额下忽略货币/步骤（CLP/JPY）。
没有相等性→双重取消配额。
所有Tenant的单个RATE池→问题的Shering。
没有审计→无法解释拒绝。

17）快速食谱

投注接受："max_bet"=min（区域，游戏，提供商，定制RG）；RATE在'/bets上。place'=20 rps/player, QUOTA=500费率/日。
存款："deposit_daily/monthly"+"deposit_single"；批准PSP限制。
会话：'session_duration' hard+提醒每隔N分钟（软）。
API保护：按密钥"ip_asn"和"tenant_id"进行全局RATE；发行版的金丝雀窗口。

18）售前支票清单

• 已记录了特异性层次结构和merge策略（最特殊的wins，deny> allow）。
• 具有"scope"、"kind"、"type"、窗口、货币和优先级的数据模型。
• 应用点：网关（RATE）,域（QUOTA/现金）,适配器（提供商）。
• 异位性（"operation_id"）和按键序列化；计数器是原子。
• 可观察性：决策度量，窗口滞后，变量；使用"matched_limit_id"进行跟踪。
• 验证和不可更改的更改和响应审核。
• 测试包：contract/property/golden/chaos/E2E。
• Multi-tenant fairness和data residency遵循。
• SOFT限制的UX：可理解的消息，"remaining/retry_after"。
• 事件的花花公子与合规和支持保持一致。

结论

极限层次结构是决策系统，不是一组不同的数字。明确的特异性和优先顺序、统一的数据模型、正确的应用点、相容性和可观察性将限制转变为可靠的安全性和合规性回路,可跨性、区域和产品进行扩展,并且不会干扰增长。