پروتکل های ارتباطی مشترک

1) چرا اکوسیستم نیاز به پروتکل های یکنواخت دارد

اکوسیستم شامل اپراتورها، استودیوها/RGS، جمع کننده ها، PSP/APM، ارائه دهندگان KYC/AML، وابستگان و خدمات تحلیلی است. پروتکل های تعامل مشترک حذف «باغ وحش» از ادغام، سرعت بخشیدن به onboarding، کاهش هزینه های پشتیبانی و خطرات حوادث، و همچنین ارائه سازگاری زمانی که پوسته پوسته شدن (افقی، عمودی و مورب).

اهداف: قابلیت همکاری خارج از جعبه، SLO های قابل پیش بینی، امنیت داده ها، مهاجرت های قابل تکرار.

2) لایه حمل و نقل و فرمت

HTTP/2/3، gRPC - برای API های همزمان با تاخیر کم ؛ WebSocket - برای رویدادهای جریان/مدیران ؛ WebRTC (SRTP/QUIC) - برای محتوای زنده صوتی/تصویری.

• JSON - API های B2B خارجی و وب سایت ها (قابلیت خواندن).
• Protobuf/Avro - ادغام داخلی اتوبوس/عمیق (تکامل فشرده سازی/مدار).
• فشرده سازی/اتصال: gzip/br برای JSON ؛ ZSTD برای Protobuf/آورو.
• محلی/زمان: ISO-8601 در UTC، مقدار در حداقل واحد پولی (عدد صحیح).

3) احراز هویت، مجوز، اعتماد

OAuth2/OIDC برای برنامه های مشتری/شریک (نشانه های کوتاه مدت، PKCE، حوزه ها).
mTLS برای S2S بین مناطق مورد اعتماد JWS/HMAC - امضای درخواست ها و وب سایت ها.
RBAC/ABAC: نقش ها و ویژگی ها (صلاحیت، مستاجر، سطح ریسک).
کلید و چرخش: KMS/خرک، عمر کوتاه، چرخش خودکار (از جمله JWKS).
کنترل خروج، اجازه لیست دامنه و ASN، DNSSEC/DoT/DoH در مناطق حساس.
جداسازی مستاجر: کلید های هر مستاجر، سهمیه ها، محدودیت ها، فضای نام در تایر.

4) قراردادهای API (REST/gRPC) - کانن

نسخه بندی: '/v {n} 'در URI برای استراحت ؛' بسته بندی vN 'برای gRPC. تکامل جزئی - بی عیب و نقص ؛ شکستن تغییرات - از طریق جدید عمده. افسردگی از طریق سیاست (§ 12 را ببینید).
Idempotency: «Idempotency-Key» در عملیات نقدی/بحرانی POST/PUT/PATCH ؛ صرفه جویی برای N ساعت.
صفحه بندی: نشانگر ('nextPageToken')، نه 'offset/limit' ؛ مرتب سازی سازگار.
محدودیت ها: '429 Too Many Requests' + هدر سهمیه ('X-RateLimit-')، jitter در retras.
خطاها: کدهای قابل خواندن ماشین/کد های فرعی, 'correlationId', نقشه فیلد اعتبار سنجی.
زمانبندی و عقب نشینی: تاخیر نمایشی + لرزش ؛ اشتباهات نا امن را نادیده نگیرید.

سیاست سازگاری: تغییر ناپذیری معنای میدان ؛ زمینه های جدید - اختیاری

5) مدل رویداد و اتوبوس (EDA)

رجیستری طرح: قرارداد برای هر رویداد، تکامل با سازگاری با عقب.

• 'click', 'session', 'bet '/' spin', 'round _ start '/' round _ result',
• 'deposit '/' withdrawal', 'psp _ auth', 'kyc _ status', 'fraud _ signal',
• 'reward _ grounded', 'leaderboard _ update', 'feature _ toggle'.
• کلیدهای مهمانی: 'playerId', 'campaignId', 'tableId', 'operatorId' (انتخاب بر اساس دامنه).
• تحویل: حداقل یک بار با idempotency کسب و کار ؛ برای مجموع پولی - حماسه/txn-outbox.
• سفارش: «سفارش تضمین شده در داخل کلید»، کلیدهای متقابل - از طریق ارکستراسیون.
• معناشناسی زمان: 'eventTime' + 'ingestTime'; پدر بزرگ به '(eventId' idempotencyKey) '.

6) Webhooks و تضمین تحویل

امضا: JWS/HMAC با «t» (برچسب زمان) و «بچه»، بررسی پنجره ± 5 دقیقه، پخش ممنوع است.
Retrai: عقب نشینی با jitter تا دقیقه T، تلاش های ثابت، ارسال مجدد تنها در 5xx/timeout.

Idempotency: 'eventId' + امضای بدن ؛ پردازش «حداقل یک بار»

Webhook ثبت رویداد: resampling تاریخچه زمانی که از همگام سازی.
امنیت: mTLS تا آنجا که ممکن است، اجازه می دهد لیست IP/ASN، CSRF به یقه های سمت سرور اعمال نمی شود.

7) داده ها و حریم خصوصی (حریم خصوصی توسط طراحی)

به حداقل رساندن PII: نشانه گذاری شناسه ها ('playerId' pseudonymized است)، جدایی از حوزه های داده.
قراردادهای داده: DPA/DPIA، اهداف، دوره های نگهداری، جریان های مرزی (کشورهای لیست سفید).

سیاست های حسابرسی/خطی: چه کسی/چه زمانی/چرا ؛ لاگهای تغییرناپذیر (WORM)

قوانین RG/اخلاق: ممنوعیت پیشنهادات تهاجمی برای بخش های آسیب پذیر ؛ یک چارچوب قانونی مشخص

8) ثبات و معاملات

سازگاری قوی - کیف پول/تعادل/پرداخت.
احتمالی - ویترین، مدیران، تله متری.

Sagas برای معاملات تجاری توزیع شده ؛ جبران خسارت برای لغو

دقیقا یک بار در مفهوم کسب و کار: کلید idemotent و گرداننده قطعی

9) قابلیت مشاهده و SLO

ردیابی: پایان دادن به پایان 'traceId' از کلیک/webhook به پرداخت/پاداش ؛ انتشار ('W3C traceparent').
معیارهای: P50/P95/P99 API، تاخیر کارگزار، پرداخت CR/CCL، مدیران E2E.

سیاهههای مربوط: ساختار یافته، بدون اطلاعات شخصی ؛ ماسک کردن کلید/کلید

فهرست SLO: ورود به سیستم p95 ≤ 300-500 ms ؛ سپرده p95 ≤ 1. 5–2. 0 ثانیه ؛ شرط/چرخش p95 ≤ 150-250 میلی ثانیه ؛ تحویل ≥ 99. 9%.

10) عملکرد، سهمیه، حفاظت از طوفان

محدود کردن نرخ (سطل نشانه/نشتی) در L7 و در سیاست های مش.
فشار پشتی: صف قبل از بالادست شکننده (PSP/KYC).
Outlier-ejection: خودکار «خنک کننده» از backends ناپایدار است.
Circuit-breaker - هنگامی که آستانه خطا/تأخیر بیش از حد باشد، موضوع را می بندد.

سهم عادلانه: سهمیه مستاجر/کانال/منطقه ؛ اولویت حوزههای بحرانی

11) سازگاری SDK و معیارهای آزمون

SDK: مشتریان HTTP/gRPC، امضای درخواست، ردیابی Jitter، idempotency، نشانگرهای.
تست قرارداد: Postman/Newman/gRPC-conformance، PSP/KYC/شبیه ساز استودیو.
ماتریس سازگاری: نسخه های API/SDK، طرح های پشتیبانی شده، سیاست های کاهش.
Synthetics: ژنراتور رویداد و معامله، جعبه سیاه 24/7 برای نظارت.

12) نسخه و رسوب (مدیریت تغییر)

نسخه های عمده هر N ماه، با یک پنجره موازی ≥ 6-12 ماه.
تغییرات جزئی - اضافه کردن زمینه ها/روش های اختیاری بدون اصطکاک است.
کاهش: هشدار → هشدار در هدر/پاسخ → پرچم در معیارها → خاموش کردن با توجه به برنامه.
مهاجرت طرح رویداد - اضافه کردن تنها استراتژی + آداپتورهای پروکسی در مرزها.

13) امنیت پروتکل

اعتماد صفر: mTLS در همه جا، اعتقادات کوتاه مدت، اصول حداقل امتیاز.
دامنه های مخفی: جداسازی کلیدهای خواندن/نوشتن/مدیریت.

حفاظت در برابر تکرار: پنجره nonce/time در امضا ؛ ممنوعیت استفاده مجدد

فیلترهای WAF/ربات: حفاظت در برابر تقلب/کلیک کنید ؛ مثبت کاذب پایین

مناطق فروشنده: microsegmentation، VPCs/namespaces فردی، خروجی اجازه لیست.

14) حوادث و DRs

روش های اتاق جنگ: دکمه توقف برای دامنه ها (محتوا/PSP/KYC)، RACI، SLA در هر بسته ردیابی.
سناریوهای DR: نقاط ورودی دارایی (Anycast/GSLB)، برش ≤ 60-90 ثانیه، تمرینات سه ماهه.
RCA: قالب ها بدون پیدا کردن مقصر، ارتباط L3↔L7، به روز رسانی پروتکل/SDK/Runbook.

15) معیارهای موفقیت پروتکل

سازگاری: نسبت شرکایی که آزمون انطباق را گذرانده اند ؛ زمان تحویل (TTO)

قابلیت اطمینان: ادغام uptime، p95 API/bus، سهم وب سایت های موفق.
امنیت: حوادث PD = 0، زمان چرخش کلید، سهم ترافیک mTLS.
اقتصاد: هزینه هر rps/txn/رویداد، کاهش هزینه برای خدمت، زمان مهاجرت.
محصول: FTD/ARPU/LTV از استاندارد سازی (نشت CCD/پرداخت کمتر).

16) ضد الگوهای

«شکل آزاد» رویدادها: عدم وجود نمودارها و نسخه ها → رانندگی در اطراف ویترین ها و تجزیه و تحلیل ها.
دروازه L7 تنها بدون N + 1: SPOF و گلو باریک برای webhooks/PSP.
Retrai نامحدود/Jitter: طوفان ترافیک، معامله دو.
PD خام در عوض: بدون توکن سازی/DPIA → خطرات نظارتی.
صفحه بندی افست: شکاف/تکراری تحت بار.
اسرار «برای همیشه» و IP استاتیک بدون کنترل خروج.
شکستن تغییرات بدون پنجره موازی و آداپتورها.

17) چک لیست پیاده سازی

1. پذیرش کانون API (نسخه, idempotency, صفحه بندی, خطاها).
2. وارد کردن Schema Registry و نقشه دامنه کلیدهای موضوع/حزب.
3. تعهد mTLS + JWS/HMAC برای S2S و وب سایت ها ؛ چرخش کلید اتوماتیک/JWKS.
4. تنظیم محدودیت/retrays/CB/outlier-ejection و سهمیه در هر مستاجر.

5. گسترش ردیابی/معیارها/سیاهههای مربوط با یک 'traceId' تنها ؛ لیست های SLO را تایید کنید

6. DPA/DPIA را امضا کنید، توکن سازی را فعال کنید و سیاست ها را ذخیره/حذف کنید.
7. ایجاد SDK و مجموعه سازگاری ؛ سیاست تخلیه را اصلاح کنید.
8. انجام تمرینات DR/هرج و مرج و مراسم اتاق جنگ ؛ «شروع سیاه» در حداقل مجموعه.
9. پیاده سازی یک کاتالوگ پروتکل (پورتال شریک): مشخصات، نمونه ها، شبیه سازی، sandbox.

18) نقشه راه تکامل

v1 (بنیاد): کانن REST/gRPC، طرح های رویداد اساسی، امضاهای وب هوک، mTLS.
v2 (ادغام): خط لوله مهاجرت، تست انطباق، SDK، موتور قانون برای سهمیه/retrays.
v3 (اتوماسیون): خودکار سازی توسط SLI، sandboxes/simulators سلف سرویس، آداپتورهای بین نسخه ها.
v4 (حاکمیت شبکه): کمیته پروتکل متقابل شریک، SLO های مشترک/اعتبارات/مجازات ها، سیاست های مشترک PoP/لبه.

خلاصه ای کوتاه

پروتکل های مشترک تعامل «زبان» اکوسیستم هستند: API یکنواخت و قراردادهای رویداد، امنیت دقیق (mTLS/JWS)، قابلیت اطمینان و تضمین تحویل، قابلیت مشاهده و SLO ها، مهاجرت های مدیریت شده و DR به دنبال کانن، شرکت کنندگان سریع تر هستند، کمتر سقوط می کنند، به راحتی مقیاس می شوند و به طور قابل پیش بینی رشد می کنند - به شرایط حفظ حریم خصوصی و الزامات قانونی.