GH GambleHub

محدود کردن سلسله مراتب

محدودیت یک محدودیت رسمی از یک عملیات در زمان/حجم/ارزش است. در iGaming و fintech، محدودیت ها پایه ای برای ایمنی، انطباق قانونی و مدیریت ریسک هستند. سلسله مراتب محدود مشخص می کند که کدام قانون مهم تر است و در آن برای جلوگیری از هزینه های دوگانه، بیش از شرط ها/سپرده ها، سوء استفاده از پاداش ها و نقض بازی مسئولانه اجرا می شود.

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)
قوانین و مقررات:
  • یک زمینه باریک همپوشانی گسترده ای دارد: بازیکن> منطقه.
  • هر گونه انکار صریح پیروزی اجازه می دهد.
  • اختلافات نرم/سخت به نفع سخت حل می شود.
  • با ادغام سهمیه ها/پنجره ها، حداقل مقدار مجاز (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
);

Idempotence: تمام عملیات حمل 'operation _ id' ؛ افزایش شمارنده یک بار انجام می شود (صندوق ورودی/صندوق خروجی یا مقایسه و مبادله با توجه به نسخه).

5) الگوریتم ارزیابی

1. جمع آوری نامزدها توسط «نوع» و عبور از «دامنه».
2. رتبه بندی بر اساس ویژگی (تعداد اندازه گیری های همسان) و «اولویت».
3. محدوده پارامتر: سختی (سخت> نرم)، حداقل کلاه، حداقل پنجره.
4. محدودیت سهمیه/نرخ را بررسی کنید: token-bucket (RATE) + پنجره ثابت/کشویی (QUOTA).
5. Решение: «ALLOW | SOFT_WARN | انکار» + «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) نقاط اجرای

API دروازه - حفاظت از زیرساخت: RATE (RPS), همزمانی, پشت سر هم.
خدمات دامنه - محدودیت معنایی: سپرده ها، نرخ ها، پرداخت ها، جلسات.
آداپتورهای ارائه دهنده - محدودیت ارائه دهنده تکراری/محلی (اعتبار قبل از تماس).
UX مشتری - پیشنهادات پیشگیرانه (SOFT)، «N چپ»، تایمر.

قانون: یک بار سهمیه/نشانه ها را بنویسید - جایی که عملیات غیر قابل برگشت می شود (پس از پشتیبان گیری از کیف پول/مرحله معتبر معتبر).

7) محدودیت های نقدی: سپرده/نرخ/پرداخت

در هر ارز: محدودیت ها را در ارز معامله ذخیره کنید، نه از طریق FX در پرواز.
حداقل/حداکثر: 'min _ bet'، 'max _ bet'، 'max _ payout _ single'.
Windows: 'deposit _ daily/weekly/monthly' با مرزهای ثابت (به عنوان مثال، در منطقه زمانی مجوز).
ترکیب: محدوده مجاز نهایی = تقاطع (منطقه ای ∩ نام تجاری ∩ سفارشی).

8) بازی مسئولانه (RG)

محدودیت های خود (بازیکن از خودش پرسید) همیشه سخت تر از مارک ها است.
محدودیت زمانی: «session _ duration»، «cool _ off»، «self _ exclusion».
تشدید: بیش از حد نرم → هشدار، تکرار سخت → (در پنجره).
حسابرسی: هر تغییر RG به صورت غیر جانبی (چه کسی/چه زمانی/چرا) ثبت می شود.

9) محدودیت نرخ در مقابل سهمیه: زمانی که چه

محدودیت نرخ (رمز سطل/نشت): حفاظت از افزایش ؛ درخواست در دروازه/آداپتورها.
سهمیه (پنجره ثابت/کشویی): مدیریت کل بودجه اقدامات/پول ؛ دامنه (deposit_daily، bet_count_hourly).
اغلب با هم استفاده می شود: «نرخ» (قله های فوری) + «سهمیه» (بودجه روزانه).

10) چند مستاجر و چند منطقه

محدودیت ها همیشه شامل «tenant _ id» و «region/license» هستند.
اقامت: شمارنده و ذخیره سازی - در منطقه «خانه».

عدالت: RATE/QUOTA جداگانه برای هر استخر مستاجر، بنابراین «پر سر و صدا» SLO دیگران را مختل نمی کند

11) بی نظمی و سازگاری

دستورات با 'operation _ id' ؛ تکرار نباید «مصرف» را افزایش دهد.
برای پول - مسیر دقیق: ذخیره کیف پول و افزایش شمارنده در یک معامله/حماسه (TCC).
برای RATE - استفاده از افزایش اتمی/انبار پنجره فعلی.

12) قابلیت مشاهده

معیارها:
  • 'limit _ eval _ p95 _ ms', 'decision _ rate {ALLOW, DENY, SOFT}',
  • 'quota _ remaining _ percent' by گونه های اصلی،
  • نرخ خفه شد، ترکید، افتاد،
  • 'rg _ self _ limit _ hits'، 'regulatory _ hits'.

Логи/трейсинг: 'matched _ limit _ id', 'scope _ hash', 'operation _ id', 'window _ start/reset', 'remaining'.

هشدارها: رشد «انکار »/« 429» بیش از آستانه، دستیابی مکرر به کلاه های نظارتی، «کلید داغ» توسط بازیکن/دستگاه.

13) نسخه و حسابرسی

هر قانون با «valid _ from/valid _ to»، «created _ by»، «reason _ code» است.
События: 'LimitCreated/Updated/Deleted', 'LimitHit', 'LimitDenied'.
نگه داشتن یک «عکس فوری» از قوانین فعال برای بازتولید تصمیمات تاریخی (آماده اختلاف).

14) تست

تست های قرارداد: طرح و طیف وسیعی از ویژگی ها/اولویت ها.
مبتنی بر اموال: «خاص ترین برنده»، «انکار برنده اجازه می دهد»، «حداقل کلاه».
موارد طلایی: مجموعه ای از درگیری های مرجع (مستاجر در مقابل منطقه، RG در مقابل نام تجاری).
هرج و مرج: درخواست خوشه (RATE)، تعداد نژادها، دستورات تکرار (idempointency).
E2E: مسابقات محدود در لیست چک از تنظیم کننده (سپرده/هفته/ماه).

15) کتاب های بازی

1. طوفان 429/خفه کردن در دروازه

کاهش همزمانی، افزایش موقت token-bucket، امکان اولویت بندی مسیرهای بحرانی، تجزیه و تحلیل منابع (ASN/IP).

2. شکست های توده ای توسط محدودیت قانونی

بررسی برنامه پنجره و منطقه زمانی ؛ طولانی نرم UX (توضیحات)، اطلاع انطباق.

3. شکست مثبت کاذب به دلیل مسابقه

سریال سازی را با کلید «player _ id/kind» فعال کنید، با «operation _ id» به CAS/dedup بروید.

4. اختلاف با محدودیت ارائه دهنده

همگام سازی دقیقه/حداکثر در هر بازی، اضافه کردن پیش اعتبار به آداپتور، به طور موقت کاتالوگ بازی/قرار دادن بازی را کاهش می دهد.

16) خطاهای معمول

فقدان سلسله مراتب → تقلا از جنگ بین قوانین.
محاسبه محدودیت ها در UI بدون اعتبار سرور.
جایگزینی سهمیه با محدودیت نرخ (و بالعکس).
نادیده گرفتن ارزها/مراحل با محدودیت های پولی (CLP/JPY).
بدون idempotency → دو سهمیه نوشتن کردن.
یک استخر RATE برای همه مستاجران → مشکلات برش.
هیچ شکست حسابرسی نمی تواند توضیح داده شود.

17) دستور العمل های سریع

پذیرش پیشنهاد: 'max _ bet' = min (منطقه، بازی، ارائه دهنده، RG کاربر) ؛ نرخ در "/شرط. place '= 20 rps/player, QUOTA = 500 شرط/روز.
سپرده ها: 'سپرده _ روزانه/ماهانه' + 'سپرده _ تک' ؛ پیش اعتبار محدودیت PSP.
جلسات: 'session _ duration' سخت + یادآوری هر N دقیقه (نرم).
حفاظت API: نرخ جهانی توسط کلید 'ip _ asn' و 'tenant _ id' ؛ پنجره های قناری برای آزادی.

18) چک لیست پیش فروش

  • خاص ترین برنده, انکار> اجازه می دهد.
  • مدل داده با «دامنه»، «نوع»، «نوع»، پنجره ها، ارزها و اولویت ها.
  • نقاط برنامه: دروازه (RATE)، دامنه (QUOTA/پول)، آداپتورها (ارائه دهنده).
  • Idempotency ('operation _ id') و سریال سازی با کلید ؛ شمارنده ها اتمی هستند.
  • قابلیت مشاهده: معیارهای راه حل، پنجره ها، هشدارها ؛ ردیابی با 'matched _ limit _ id'.
  • نسخه و حسابرسی غیر قابل تغییر از تغییرات و اعمال.
  • بسته تست: contract/property/golden/chaos/E2E.
  • عدالت چند مستاجر و اقامت داده ملاقات کرد.
  • UX برای محدودیت های SOFT: پیام های دوستانه، «remaining/retry _ after».
  • playbooks حادثه با انطباق و پشتیبانی تراز وسط قرار دارد.

نتیجه گیری

سلسله مراتب محدود یک سیستم تصمیم گیری است، نه مجموعه ای از اعداد متفاوت. ویژگی واضح و ترتیب اولویت ها، یک مدل داده واحد، نقاط کاربرد مناسب، بی نظمی و مشاهده پذیری محدودیت ها را به یک حلقه ایمنی و انطباق قوی تبدیل می کند که در مستاجران، مناطق و محصولات مقیاس می شود و مانع رشد نمی شود.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.