限制層次結構

限制是交易在時間/範圍/成本上的形式化限制。在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」。
• 事件的花花公子與合規和支持保持一致。

結論

極限層次結構是決策系統，不是一組不同的數字。明確的特異性和優先順序、統一的數據模型、正確的應用點、相容性和可觀察性將限制轉變為可靠的安全性和合規性回路,可跨性、區域和產品進行擴展,並且不會幹擾增長。