제한 계층 구조
한계는 시간/볼륨/값 동작의 공식화 된 제한입니다. iGaming 및 핀 테크에서 한계는 안전, 규제 준수 및 위험 관리의 기초입니다. 한도 계층은 이중 지출, 베팅/예금 초과, 보너스 남용 및 책임있는 플레이 위반을 방지하기 위해 규칙이 가장 중요하고 실행되는 위치를 지정합니다.
1) 한계 분류
적용 강도에 의하여
어려운-극복 할 수없는 (운영 금지).
부드러운 경고/마찰 (captcha, 확인), 반복 될 때 단단하게 에스컬레이션.
본질적으로
현금: 예금 금액/요금/지불; 일일/주간/월간 제한.
시간: 세션 기간, 휴식, "냉각", 타임 아웃.
양적: 트랜잭션 수, 스핀, API 요청.
요율 제한: RPS/경쟁.
인용문: 창 당 행동 예산 (주당 N).
상황: 게임/제공자/결제 방법/장치/국가 별.
소유자 별
규제/브랜드 (임차인/지역)
시스템 (플랫폼, 인프라 보호)
사용자 정의 (RG 내 자체 제한)
2) 측정 및 키 (범위 지정)
각 한계는 컨텍스트 (키) 에 바인딩됩니다
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)- 더 좁은 컨텍스트는 넓은 플레이어> 영역과 겹칩니다.
- 명백한 거부 승리는 허용합니다.
- 소프트/하드 충돌은 하드를 위해 해결됩니다.
- 쿼터/윈도우의 병합으로 최소 허용 값 (최소 한도) 이 승리합니다.
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' 가 있습니다. 카운터 증분은 한 번 수행됩니다 (버전에 따라받은 편지함/아웃 박스 또는 비교 및 교환).
5) 평가 알고리즘
1. '종류' 로 후보자를 모으고 '범위' 를 넘습니다.
2. 특이성 (일치 측정 횟수) 및 '우선 순위' 별 순위.
3. 매개 변수 범위: 경도 (경도> 소프트), 최소 캡, 최소 창.
4. 쿼터/속도 제한 확인: 토큰 버킷 (RATE) + 수정/슬라이딩 창 (QUOTA).
5. 'ALLOW | SOFT _ WARN | DENY' + '재 시도 '/' 남은'.
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) 집행 포인트
API 게이트웨이-인프라 보호: RATE (RPS), CONCurrENCY, 버스트.
도메인 서비스-의미 제한: 예금, 요금, 지불, 세션.
공급자 어댑터-중복/로컬 공급자 제한 (통화 전 유효성 검사).
클라이언트 UX-예방 프롬프트 (SOFT), "N left", 타이머.
규칙: 할당량/토큰을 한 번 기록하십시오-작업을 되돌릴 수없는 곳 (지갑/유효한 인증 단계를 백업 한 후).
7) 현금 한도: 예금/요금/지불
통화 당: FX를 통한 것이 아니라 거래 통화의 상점 제한.
Min/Max: 'min _ bet', 'max _ bet', 'max _ payout _ single'.
Windows: 고정 된 경계 (예: 라이센스 시간대) 가있는 '매일/매주/매월'.
구성: 최종 허용 범위 = 교차점 (지역 절반 브랜드 사용자 정의).
8) 책임있는 플레이 (RG)
자기 제한 (플레이어가 자신에게 물었다) 은 항상 브랜드 제한보다 강합니다.
시간 제한: '세션 _ 지속 시간', 'cool _ off', '자체 _ 제외'.
확장: 소프트 한계 → 경고를 초과하여 하드 → (창 내) 를 반복합니다.
감사: 각 RG 변경은 비 측면적으로 기록됩니다 (누가/언제/왜).
9) 요율 제한 대 쿼터: 언제
요율 제한 (토큰 버킷/누출): 서지 보호; 게이트웨이/어댑터에 적용하십시오
쿼터 (고정/슬라이딩 창): 행동/돈의 총 예산 관리; 도메인 (deposit _ daily, bet _ count _ hourly) 에 적용하십시오.
종종 함께 사용됩니다: 'RATE' (인스턴트 피크) + 'QUOTA' (일일 예산).
10) 다중 테넌트 및 다중 지역
한계에는 항상 '테넌트 _ id' 및 '지역/라이센스' 가 포함됩니다.
거주지: "가정" 지역의 카운터 및 보관.
공정성: 임차인 풀당 분리 된 RATE/QUOTA로 인해 "잡음" 이 다른 사람들의 SLO를 방해하지 않습니다
11) 이념과 일관성
'operation _ id' 명령; 반복하면 '소비' 가 증가해서는 안됩니다.
돈-엄격한 경로: 한 거래/사가 (TCC) 의 지갑 보유 및 증분 카운터.
RATE의 경우 원자 증분/창고 전류 창을 사용하십시오.
12) 관찰 가능성
메트릭:- 'limite _ eval _ p95 _ ms', 'decision _ rate {ALLOW, DENY, SOFT}',
- 주요 종에 의한 '쿼터 _ 남은 _ 퍼센트',
- 'rate _ throttled', 'burst _ drop',
- (PHP 3 = 3.0.6, PHP 4)
'일치 _ limate _ id', 'scope _ hash', 'operation _ id', '창 _ 시작/재설정', '남은'.
경고: 임계 값보다 'DENY '/' 429' 의 성장, 규제 한도의 빈번한 달성, 플레이어/장치의 "핫 키".
13) 수정 및 감사
각 규칙은 '유효한 _ from/유효한 _ to', '만들어진 _ by', 'reason _ code' 입니다.
확인: '제한/업데이트/삭제', '제한', '제한 거부'.
역사적 결정 (분쟁 준비) 을 재현하기 위해 적극적인 규칙의 "스냅 샷" 을 유지하십시오.
14) 테스트
계약 테스트: 특이성/우선 순위의 체계 및 범위.
재산 기반: "가장 구체적인 승리", "승리를 거부하십시오", "최소 한도".
황금 사례: 일련의 참조 충돌 (테넌트 대 지역, RG vs 브랜드).
혼돈: 요청 스파이크 (RATE), 레이스 수, 반복 명령 (demotency).
E2E: 규제 기관의 체크리스트 (예금/주/월) 의 일치 제한.
15) 플레이 북
1. 게이트웨이에서 폭풍 429/스로틀 링
동시성을 줄이고 토큰 버킷을 일시적으로 늘리고 중요한 경로의 우선 순위를 정하고 소스를 분석합니다 (ASN/IP).
2. 규제 제한에 의한 대량 실패
창 일정과 시간대를 확인하십시오 소프트 UX (설명) 를 연장하고 규정 준수를 알립니다.
3. 경주로 인한 거짓 긍정적 실패
'player _ id/kind' 키로 직렬화를 사용하고 'operation _ id' 로 CAS/dedup으로 전환하십시오.
4. 공급자 제한이있는 불일치
게임당 min/max를 동기화하고 어댑터에 사전 검증을 추가하고 게임 카탈로그/배치를 일시적으로 낮추십시오.
16) 전형적인 오류
계층 구조 부족 → 규칙 간의 줄다리기.
서버 검증없이 UI의 한계 계산.
요율 제한이있는 할당량 대체 (및 그 반대).
금전적 한도 (CLP/JPY) 로 통화/단계를 무시합니다.
demempotency → 이중 할당량 상각이 없습니다.
모든 임차인을위한 단일 RATE 풀 → 전단 문제.
감사 → 실패를 설명 할 수 없습니다.
17) 빠른 레시피
입찰 수락: 'max _ bet' = min (지역, 게임, 공급자, 사용자 RG); RATE on '/베팅. 장소 '= 20 rps/player, QUOTA = 500 bets/day.
예금: '예금 _ 매일/월' + '예금 _ 단일'; 사전 검증 PSP 한계.
세션: N 분마다 '세션 _ 지속 시간' 하드 + 알림 (소프트).
API 보호: 키 'ip _ asnd' 및 'tenant _ id' 에 의한 글로벌 RATE; 릴리스를위한 카나리아 창.
18) 사전 판매 점검표
- 대부분의 구체적인 승리, 거부> 허용.
- '범위', '종류', '유형', 창, 통화 및 우선 순위가있는 데이터 모델.
- 응용 프로그램 포인트: 게이트웨이 (RATE), 도메인 (QUOTA/화폐), 어댑터 (공급자).
- Idempotency ('operation _ id') 및 키별 직렬화; 카운터는 원자입니다.
- 관찰 가능성: 솔루션 메트릭, 창 지연, 경고; (PHP 3 = 3.0.6, PHP 4)
- 변경 및 작업에 대한 검증 및 변경 불가능한 감사.
- 테스트 팩: 계약/속성/황금/혼돈/E2E.
- 다중 임차인의 공정성과 데이터 레지던트가 충족되었습니
- SOFT 한계 용 UX: 친숙한 메시지, '남은/다시 시도'.
- 사건 플레이 북은 규정 준수 및 지원과 일치합니다.
결론
한계 계층은 서로 다른 숫자 세트가 아닌 의사 결정 시스템입니다. 명확한 특이성과 우선 순위, 단일 데이터 모델, 올바른 응용 프로그램 포인트, dempotence 및 관찰 성은 한계를 세입자, 지역 및 제품에 걸쳐 확장되어 성장을 방해하지 않는 강력한 안전 및 규정 준수 루프로 바꿉니다.