چرا کازینوها به معماری مدولار تغییر می کنند

چرا مدولار کازینو

یکپارچه تاریخی باعث کاهش رشد می شود: هر تغییر باعث انتشار کل سیستم، ادغام ارائه دهندگان و PSP به SLO ها، به روز رسانی های انطباق - در سراسر کد می شود. معماری مدولار (دامنه محور + API قرارداد + رویدادها) اجازه می دهد تا:

به سرعت نمایش ویژگی ها و اتصال ارائه دهندگان بدون هماهنگی «همه با همه» ؛
مقیاس انتخابی (ویدئو زنده به طور جداگانه از ثبت نام نقدی، کیف پول به طور جداگانه از کاتالوگ بازی) ؛
جدا کردن خطرات (خطا در تبلیغی کیف پول را پایین نمی آورد) ؛
مطابق با مجوز (ورود به سیستم/نسخه/سیاست در مرزهای دامنه);
کاهش TCO از طریق قراردادهای روشن، استفاده مجدد و اتوماسیون.

نقشه دامنه (مثال شکست)

کیف پول/لجر - پول، پرچین ارز، تعادل پاداش، PITR، حسابرسی.

صندوقدار/پرداخت - PSP، در رمپ/خارج از رمپ، KYT، idempotent webhooks.

Gaming Bridge - آداپتورهای ارائه دهنده، نرمال سازی دور/شرط.

کاتالوگ/لابی - بازی ها، ارائه دهندگان، ویژگی ها و قوانین نمایش.

Promo/Bonus - قوانین سهام، کوپن، شرط بندی.

KYC/AML/RG - تأیید هویت، تحریم/PEP، محدودیت ها و خود حذفی.

تجربه - ظاهر، CDN، i18n، A/B، Telegram WebApp.

تله متری/تجزیه و تحلیل - رویدادها، ویترین، ML/AI.

انطباق و حسابرسی - گزارش MGA/UKGC، آرشیو WORM.

💡 هر ماژول دارای طرح داده خود، API و قرارداد رویداد است. تعامل - از طریق اتوبوس رویداد و رابط های به شدت نسخه.

اصول معماری مدولار

1. مرزهای DDD (زمینه محدود). دانش روشن از داده ها و منطق.

2. API اول + رویدادها. OpenAPI/AsyncAPI، JSON-Schema، تست های قرارداد.

3. نسخه و سازگاری. 'v1 → v1. 1 → v2 '(گسترش → مهاجرت → قرارداد).

4. Idempotency & دقیقاً یک بار قصد. درخواست کلید، deduplication رویداد.

5. امنیت پیش فرض mTLS، امضاهای HMAC، JWT کوتاه، RBAC/ABAC.

6. آزادی های مستقل استقرار قناری/آبی-سبز، مهاجرت «دو نویسنده» ممنوع است.

7. قابل مشاهده بودن End-to-end 'traceId'، معیارهای SLO در هر ماژول.

8. پرچم های Ficha ترافیک/بخش جغرافیایی/کاربر، عقب نشینی امن.

لایه ادغام: نحوه اتصال ارائه دهندگان و PSP

الگوی Adapter/Bridge: هر ارائه دهنده بازی/پرداخت یک پلاگین با یک قرارداد پلت فرم واحد است.

بازی ها: عادی سازی 'roundId/betId/status', نقشه برداری خطا, کش محدود.

پرداخت: یک رابط واحد 'مجاز/ضبط/بازپرداخت/پرداخت'، webhooks با idempotency.

Disconnectability - آداپتور معیوب به تعمیر و نگهداری بدون تاثیر بر دیگران منتقل می شود.

قرارداد نمونه (قطعه OpenAPI):

پست/کیف پول/بدهی یامل:
درخواست بدن:
محتوا:
نرم افزار/JSON:
طرح:
$ref: '#/components/schemas/DebitRequest @v1'
پاسخ ها:
'200': {$ref: '#/components/schemas/DebitResult @v1'}
'409': {شرح: IDEMPOTENT_REPLAY}

رویدادها به عنوان «سیستم گردش خون»

اتوبوس (کافکا/NATS) رویداد →:

خوب شد. قرار داده شده، دور. حل و فصل، پرداخت. درخواست شده/تایید شده، kyc. verified/failed ',' rg. limit_set'، پاداش صادر شده/مصرف شده، صندوقدار. وب سایت. دریافت شده، کیف پول. نگه دارید/آزاد '،' هشدار. slo_breach' است.

قوانین و مقررات:

رویدادها گذشته را لغو نمی کنند ؛ تنظیمات - با رویدادهای جبران جداگانه.
هر ماژول فقط رویدادهای اصلی، مشتقات خود را به عنوان موضوعات جدید می نویسد.

داده ها: لایه ها و سازگاری

OLTP در هر ماژول: معاملات جداگانه Postgres/MySQL/KeyDB.

OLAP/storefronts: ClickHouse/BigQuery از رویدادها ساخته شده است ؛ OLTP و تجزیه و تحلیل مخلوط نیست.

فروشگاه ویژگی/ML: لایه مستقل OLTP با نسخه های ویژگی و TTL.

سازگاری: استراتژیک نهایی بین ماژول ها و برای پول - ACID محلی + اقدامات idemotent در مرزها.

استقرار و مقیاس بندی

ظروف (Docker/K8s): ماژول autoscale (کیف پول - CPU/IO ؛ ویدئو زنده - شبکه ؛ پل - RPS).

جداسازی محیط: سیاست های شبکه، اسرار فردی/کلید در هر ماژول، فروشگاه های مختلف PII/پول/تله متری.

شکل دادن به ترافیک: پرچم های ویژگی، سهم قناری، مسیرهای منطقه ای.

DR/HA: چند AZ ؛ دارایی بدهی برای پول، دارایی دارایی برای خواندن/رسانه ها.

انطباق «دوخته شده» به ماژول ها است

KYC/AML/RG یک ماژول اختصاصی با سیاست ها و یک گزارش راه حل («policyVer») است.

حسابرسی/WORM - فروشگاه غیر قابل تغییر از رویدادهای پول/دور/پرداخت.

گزارش - صادرات توسط حوزه های قضایی (MGA/UKGC)، SLA برای کامل بودن/به موقع بودن.

جریان نمونه

نرخ → محاسبه → پرداخت

1. «gaming-bridge» «bet. posted» (idempootent) را ارسال می کند.

2. «wallet» کیف پول را نگه می دارد و منتشر می کند. صبر کن.

3. "gaming-bridge" نتیجه ارائه دهنده → "دور می شود. مستقر شد.

4. "wallet" در نظر می گیرد "حل و فصل" (انتشار/پرداخت) → "کیف پول. مستقر شد.

5. «promo» حوادث را مصرف می کند و پاداش → 'پاداش می دهد. صادر شده است.

میز نقدی (سپرده)

1. «cashier» یک پرداخت ایجاد می کند. قصد 'с' Idempotency-کلید '.

2. PSP خواستار webhook → صندوقدار. وب سایت. دریافت شد ".

3. کیف پول. در واقع اعتباری → یک رویداد برای تجزیه و تحلیل و RG.

تغییرات بدون خرابی (گسترش → مهاجرت → قرارداد)

1. گسترش: فیلدها/نقاط پایانی اضافه شده به 'v1. 1، مشتریان قدیمی شکستن نیست.

2. مهاجرت: مصرف کنندگان خواندن چیزهای جدید، نوشتن در هر دو نسخه (دو نوشتن فقط برای غیر پولی).

3. قرارداد: اعلام شده EOL 'v1. 0 '، پس از N هفته به عنوان برنامه ریزی شده حذف شده است.

مهندسی پلت فرم

مسیرهای طلایی: قالب های ماژول (repo askeleon، CI/CD، هشدارها، SLO، اسرار).

تست های قرارداد: تست های Pact/AsyncAPI در CI ؛ محیط ادغام با ارائه دهندگان جعلی.

کاتالوگ خدمات (پشت صحنه): مالک، SLA، نسخه های API، کتاب های حادثه است.

معیارهای موفقیت مدولار

زمان سرب از ایده تا انتشار تولید ↓ X بار.

فرکانس انتشار توسط ماژول ↑ (در روز/هفته)، ↓ نرخ تغییر شکست.

MTTR در حوادث ↓ (به دلیل انزوا).

هزینه Infra/GGR پایدار یا ↓ با رشد ترافیک (مقیاس انتخابی) است.

زمان یکپارچه سازی ارائه دهنده/PSP (از جلسه توجیهی تا تولید) ↓.

ضد الگوهای

میکروسرویس ها برای میکروسرویس ها بدون مرزهای داده روشن، اتصال و پیچیدگی در حال رشد است.

DBs/نمودارهای مشترک بین ماژول ها. کشتن انزوا و آزادی های مستقل.

رویدادهای بدون نسخه/قرارداد. شکستن مصرف کنندگان «بی سر و صدا».

نوشتن دوگانه برای پول خطر ناسازگاری تنها گام های بیهوده از طریق یک نویسنده است.

جهانی «لایه ابزار» با همه چیز. تبدیل به یه مونولیت مخفی میشه

بدون پرچم ویژگی و سوئیچ کشتن. هر اشتباهی بلافاصله به همه ضربه میزند.

ترکیب OLTP/OLAP. گزارش ها نرخ ها/کیف پول را کاهش می دهند.

قابل مشاهده نیست. هیچ چیز برای اندازه گیری حوادث SLO و لینک وجود ندارد.

چک لیست انتقال معماری مدولار

استراتژی و دامنه ها

زمینه های محدود، صاحبان و KPI های ماژول تعریف شده اند.
نقشه تعامل: API/رویدادها، بحرانی و SLO.

قراردادها و امنیت

OpenAPI/AsyncAPI + JSON-Schema ؛ نسخه و چرخه زندگی
mTLS/HMAC، کوتاه JWT، RBAC/ABAC در مرزها.

داده ها

تقسیم OLTP ؛ رویدادها منبع OLAP هستند.
Idempotency در API/webhooks, پیام deduplication.

CI/CD & انتشارات

قناری/آبی سبز، پرچم ویژگی، modulo autoscale.
تست قرارداد در CI ؛ محیط زیست با ارائه دهندگان جعلی.

قابل مشاهده بودن

سیاهههای مربوط/معیارها/مسیرهای پیاده روی با 'traceId' ؛ داشبورد SLO
هشدارها توسط معیارهای کسب و کار (VOID، رد، تاخیر پرداخت).

تطابق پذیری

آرشیو WORM از پول/دور، صادرات گزارش نظارتی.
KYC/AML/RG به عنوان یک ماژول جداگانه با ورود به سیستم راه حل.

نمونه های کوچک

همه چيز روبراهه. حل و فصل @v1:

جی سون
{
"رویداد ":" دور. حل و فصل», «V «:» 1», «roundId»:» R-2025-10-17-evo-23», «gameId «: «evo _ blackjack _ 23», «شرط «: [{«betId «: «b _ 92f «, «playerId»:» p _ 1»,» سهام»:» 10. 00، "پرداخت": "15. 00، «نتیجه»: «WIN»} «، ts»: 2025-10-17T14: 23:13. 120Z," "traceId ":" tr _ 5f1"
}

کیف پول ایده آل:

وب سایت
پست/کیف پول/حل و فصل
X-idempotency-کلید: 9a7f-2b1c
{
"roundId":" R-2025-10-17-evo-23"، "عملیات ": [{"playerId":" p _ 1"،" دلتا":" 5. 00 "، "ارز":" EUR"}]
}

معماری مدولار پلت فرم کازینو را از یک ترکیب شکننده به ترکیبی از دامنه های قابل اعتماد تبدیل می کند: هر کدام با قراردادهای خود، داده ها و SLO. این سرعت ادغام و انتشار، فراهم می کند مقیاس انتخابی، ساده انطباق، و کاهش خطرات حادثه. با برجسته کردن مرزهای دامنه، قراردادها و رویدادها شروع کنید، در امنیت و قابلیت مشاهده قرار بگیرید - و شما یک پلت فرم را با محصول رشد می دهید، نه آن را کند می کند.