איך עובד כל הקופה

מאמר מלא

💡 18+. החומר מיושם בהנדסה, ללא קריאה לשחק. תנאים: פלטפורמה - PAM/ארנק/שולחן מזומנים/בונוסים/RG; RGS - Game Server (ליבה של משחקי אולפן); אגרגטור - שכבה מאוחדת עבור RGS מרובה; שירות ג 'יי-פי.

1) מהי מערכת הקופה והיכן היא עומדת במערכת האקולוגית

מערכת הקופה היא שירות נפרד (לפעמים מקבץ של שירותים) שאוסף תרומות מהימורים, מנהל בריכות ומנצח טריגרים, מחשב את חלוקת הפרסים ויוזם תשלומים דרך לולאת התשלומים של המפעיל. זה משתלב:

עם RGS (הודעות על תעריפים/תוצאות וכישורים), עם פלטפורמה/ארנק (כתיבת תרומות וזכיות זיכוי), עם אגרגטור (ניתוב מאולפנים/מותגים רבים), עם BI/רגולטור (טלמטריה ודיווח).

2) סוגים של קנקנים (ואילו שינויים ב ־ API)

1. סכום הפרס הידוע מראש. אין בריכה ב API, רק בדיקות מצב ואשראי.

2. הבריכה גדלה מתרומות הימורים. אנחנו צריכים נקודות סוף של התרומה ופרסום הגודל הנוכחי.

3. מולטי-רובד (Multi-tier: Mini/Major/Grand): בריכות מקבילות מרובות בעלות סיכויים שונים.

4. רשת נגד מקומית: בריכה מקומית - מפעיל אחד/מותג; רשת - סה "כ עבור מפעילים/מותגים/אזורים רבים (רב-שכפול ושכפול הם קריטיים).

5. זמן/אירוע: בריכה עם תאריך יעד או על לוח זמנים (טיימרים ושרטוטים אוטומטיים נחוצים).

3) הזמנות כספיות

מקור האמת על האיזון הוא הארנק/ספר החשבונות של הפלטפורמה. JP מאחסן רק את מצב הבריכות וההתחייבויות.

כל עסקאות הכסף הן idempotent (מפתחות 'jp _ curb _ id', 'jp _ trigger _ id',' jp _ payout _ id').

תשלומים אבודים/כפולים = 0. פיצוי - רק על ידי אירועים (סאגות), לא על ידי עריכת נתונים ידנית.

תרומה נפרדת, הדק, ותשלום כעסקאות סטנדרטיות עם הטלמטריה שלך.

4) חוזי התייחסות ל ־ API

4. 1 RGS/abgregator JP (תרומות והפעלות)

'POST/v1/jp/תרומות' - חשבון תרומת בריכה

ג 'סון
{
” : uid-1”, ” : 42”, ” : grand-eu-01”, ” ”: ” ”. 00, ”מטבע”: ”EUR”, ”contrib”: [”סכום”: 0. 02, "מטבע": "EUR"), " :"  ""  "
}

'פוסט/v1/jp/מועמדים' - בקשה להשתתפות/אימות של תנאים (אופציונלי)

תשובה: ”זכאי: אמת/שקר”, משקל או סיכוי, חוקים.

”פוסט/v1/jp/מפעיל” - הקלטת העובדה של פעולה

ג 'סון
{
” ”: ”uid-2”, ” ”: ”grand-eu-01”, ”סיבה”: ” ”: ” ”
}

💡 שים לב: בכמה מודלים, הטריגר מופעל על ידי JP עצמו (רולטה פנימית), ואז 'טריגרים' נקראים JP * platforma וה-RGS מנויים לאירוע.

4. 2 JP # פלטפורמה (תשלומים/הוראות)

'POST/V1/ארנק/reserve' - (אופציונלי) מתן תשלום עתידי

”פוסט/v1/ארנק/קרדיט” - השחקן זוכה בקרדיט

ג 'סון
{
” ”: ”uid-3”, ” : 42”, ” ”: ”grand-eu-01”, ”sume”: 00, ”מטבע”: ”EUR” ”,” meta ”:” ”:” ”mass”: ”מנותק =” שווא ”,” tier ”:” ”grand'” ”,” idempotency_key": ”” jp_p_grand_r_123
}

תגובות פלטפורמה: 'אשראי. בסדר	נכשל, עם קודי סיבה (RG/AML, גבולות משיכה, סנקציות, Geo-block).

4. 3 פרסמו סטטוס בריכה (לחזיתות/וידג 'טים)

'GET/v1/JP/bolls/üpool _ id' = = גודל נוכחי, זרע, כובע, מספר המשתתפים, ETA, וכו '.

'GET/V1/JP/בריכות' = רשימת בריכות על ידי מותג/אזור עם מסננים.

5) מודל אירוע (קפקא/פולסר) ודיאגרמות

נושאים בסיסיים:

'jp. תרומה. רשומה &fost
'jp. בריכה. מעודכן (גודל, עדכונים תחרותיים)
'jp. הפעל &fost

'jp. תשלום. מתבקש	נזקפת לזכותו של	כשל &ffost
"וואלט. אשראי. "(שיקוף עבור סאגות)
'rg. הגבלה. הכה ',' aml. התראה. נפתח '(אם התשלום חסום)
ביקורת חשבונות. הגדרה. השתנה '(גבולות, זרע, כובע, הפצה)

חוזים: Avro/JSON Schema + Schema Registry, מפתחות השתתפות "terant _ id'," pool _ id', "player _ id'. ורסינינג, התאמה לאחור.

6) אלגוריתמי טריגר (ברמה גבוהה)

הסתברות (p-יציב): עבור כל סיבוב מוסמך אנו יוצרים להיט עם הסתברות 'p' (תלוי בסוג הבריכה/רמה).

הטווח (must-drop): הבריכה חייבת ליפול לסכום המכסה או המועד הסופי - לשמור על האקראיות הפנימית בטווח [ מין, מקסימום ], לפרסם cap/ETA.

ניהול זרעים ואנטרופיה: זרעי שרת + מלח עגול; נוטש את מושבי הקופה של הלקוח. כל השינויים בזרעים נמצאים בביקורת תולעת.

כנות: הטריגר אינו צריך להיות תלוי באישיותו הספציפית של השחקן (מלבד כללי גיאו/רישיון/הסמכה). כל מטרה ”אישית” היא טאבו.

7) SLO וביצועים

p95 'תרומה' <120 ms, p99 <250 ms.

p95 'trigress * credit' <500 ms (ללא תשלום חיצוני).

”תשלום אבוד/משוכפל” = 0 (מסומן על ידי בדיקות חוזה).

משלוח אירוע לבי-איי, 5 דקות.

זמינות API לנתיבים קריטיים 99. 95%.

8) בטיחות וציות

חתימות MTLS + (HMAC/EDDSA) בכל S2S שיחות אסימונים קצרי ימים.

אפס אמון: מדיניות רשת/רשת, מינימום הרשאות, מקטע אחר אזור.

ביקורת תולעת של שינויים לגבולות, נוסחאות, זרעים/אנטרופיה, תצורות בריכה.

התמחות GDPR/Data/PCI: PII ויומנים - באזור; טוקניזציה של שדות רגישים; איסור קריאות חוצה-אזור.

RG/AML: אורות בלמים סינכרוניים על תשלום; העלאות SAR/STR הן אוטומטיות.

9) קוהרנטיות וסאגות

תרומה ('תרומה') - תיקון ב JP, לפרסם 'jp. תרומה. מוקלט '.

טריגר (”מופעל”) - יוצר מחויבות; ג 'יי-פי משגר ”תשלום” סאגה.

תשלום ("תשלום. # ארנק מבוקש. אשראי. בסדר) - מסיים את הסאגה; עם ריטריי מזויף עם שכפול.

Outbox/CDC היא הדרך היחידה לפרסם אירועים; בלי חוטבי עצים ”עוקפים”.

10) טלמטריה ולוחות מחוונים

עסקים:

”בריכה _ מידה”, ”קונטריב _ קצב”, ”avg _ contrib _ per _ aber”, ”time _ to _ drop”, ”payouts _ count/sum”, ”tier _ distribe”.

טכני:

p50/p95/p99 ”תרומה”, ”טריגר”, ”תשלום”;
קצב שגיאה (5xx/4xx/business), סערות מחדש, תור לג;
"וואלט. אשראי 'latency/ok-rate; עימות עדכון בריכה.

התראות:

גדילה 'payout. נכשל> x% על ידי מותג/אזור, 'pool _ size'> cap - Y% של זמן (טעות תצורה), סחיפה בין 'pool _ size' וכמות תרומת פיוס> Z ppm.

11) עמידות מרובה ובידוד

כל הבקשות והאירועים מסומנים 'דייר _ id/brand _ id/license/region'.

בריכות מקומיות/רשת מופרדות פיזית (DB/cluster) תחת רישיונות/אזורים שונים.

אבטחה ברמת RLS ומסווה בחנויות BI.

מפתחות/סודות נפרדים ורווחים סכמטיים למותג/אזור.

12) שילוב עם בונוסים/טורנירים

התרומות אינן מגדילות את הבקבוק ישירות; התרומה לבונוס באה מההתערבות, לא מהתרומה.

טורנירים עשויים להעניק נקודות על השתתפות JP או תרומה גבוהה. "מקור - אירועים 'jp. תרומה. הקליט את jp. מופעל '.

כלל חובה: מכניקת הזכיות אינה משנה את ה-RTP הבסיסי של המשחק; אחרת יש צורך בהסמכה נפרדת.

13) בדיקות ושיטות תוהו ובוהו

בדיקות חוזה RGS↔JP↔koshelyok: משלוח כפול, עיכובים, מחוץ לסדר, רולבק.

בדיקות עומס: סערה של הימורים והפעלות, מפרקי בריכה.

תרגילי כאוס: נפילת אזור JP, ארנק לא מקוון, דסינכרוניזציה בזמן; בדוק את התיבה וההשפלה (הפסקה מפעילה/אין תרומות חדשות).

14) רשימות בדיקה

עבור סטודיו/RGS

[ תרומתו של ] Idempotent "ונכונה" סיבוב _ id'/" הימור _ id'.

[ ] ללא פרסומים ”עוקפים” עסקאות (Outbox/CDC בלבד).

[ ] בדיקות של שכפולים/טריגרים/פיצויים חוזרים ונשנים.

[ מגבלות ההימור/ההסמכה ] מועברות לג 'יי-פי.

עבור אופרטור/פלטפורמה

[ ] לדג 'ר הוא מקור האמת,' ארנק. קרדיט עם שכפול.

[ ] תחנות RG/AML מעובדות בתשלום; דוחות SAR/STR.

[ ] p95 'trigress = קרדיט' מחוונים, שיעור שגיאות, פיוס בריכה.

עבור הבעלים של JP

[ ] ביקורת תולעת של שינויי נוסחה/זרע/גבול.

[ תרשימי אירוע ] ברישום ורישום.

[ ] ד "ר: RPO/5 min, RTO/30 min; תרגילים קבועים.

[ ] RLS/בידוד על ידי מותג/רישיון; מפתחות/סודות לכל אזור.

15) דגלים אדומים (נגד תבניות)

עריכה ידנית של מידות בריכה ותשלומים במסד הנתונים.

חוסר אידמפוטנטיות * לשכפל הלוואות.

פרסום טלמטריה ללא outbox/CDC = ”אבודים” תרומות/טריגרים.

ערבוב מח "ש ונתונים כספיים של אזורים שונים.

כל הקופה שמשפיעה על ה-RTP של משחק הבסיס ללא אישור חדש.

אין ארנק ופיוס בריכה; דיווחים מבוססים על OLTP קרבי.

Jackpot Systems API הוא חוזה אירועים כספי בין אולפן, פלטפורמה ומפעיל. הבסיס שלה: אידמפוטנטיות וסאגות, בידוד קפדני של כסף, מזימות אירועים ברורות, ביקורת אבטחה וביקורת תולעת, תצפית ו-SLO. בתכנון זה, בריכות תיקון/פרוגרסיביות ורשת בקנה מידה צפוי, התשלומים נשארים תקינים, והרגולציה והדיווח העסקי שקופים ואמינים.