ארכיטקטורה מיקרוסקופית

1) מדוע מיקרו ־ רווחים ב ־ iGaming

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

כאשר לא שווה את זה: צוות/נפח קטן, לא מתאמן DevOp, אוטומציה חלשה של בדיקות - אז מונולית מודולרית היא טובה יותר.

2) תחומים, גבולות וצוותים (טופולוגיות DDD + Team)

קווי מתאר: חשבון/פרופיל, CCM/ציות, תשלומים/ארנק, תוכן משחק/אגרגציה, בונוסים/משימות, טורנירים, שיווק/CRM, דיווח/BI.
הקשר מחובר = Data Model and Language Contract.
שינוי זורם ↔ פקודות: פקודה אחת = לולאה אחת + ה ־ SLOs שלה.
BFF (Backend for Frontend): חזיתות נפרדות עבור Web/Mobile/Partner, כדי לא לאסוף ”תזמור” על הלקוח.

3) תקשורת: סינכרוני נגד אסינכרוני

(Synchronous (REST/gRPC: כאשר יש צורך בתגובה מיידית (checking deposit limits).
Asynchron (Kafka/NATS/SQS): אירועים ותהליכי רקע (cashback accrual, דואר, עדכוני דירוג).

• נתיב קריטי = רשת מינימלית קופצת.
• שילוב תחומים מוצלבים באמצעות אירועים וחוזים.
• אל תבנה ”שרשראות של 5 + קריאות סינכרוניות” באינטרנט, השתמש ב EDA/סאגות.

4) חוזים ונימוקים

חוזה 1: OpenAPI/ASyncAPI + Schema Registry (Avro/JSON Schema).
תאימות SemVer +: הוספת שדות אינה מפרה לקוחות.
חוזים המונעים על ידי צרכנים (CDC): בדיקות אוטומטיות בסי-איי-אי (vs. regressions).
מדיניות דחייה: חלון תמיכה (12-18 חודשים), טלמטריה לגרסאות ישנות יותר.

5) אירועים, סאגות ועקביות

Outbox/Transaction Log Tailing: רשומה אטומית ”data + event”.

• תזמור (מתאם מרכזי) לתשלומים/תפוקות.
• כוריאוגרפיה (תגובה לאירועים) עבור בונוסים/משימות.
• idempotence: מפתחות על 'entitiid + action + nonce', מחסן רישום dedup.
• עקביות: ”חיצונית” - אירועים; עסקאות פנימיות במסגרת השירות.

6) נתונים ואחסון

העיקרון של ”חנות משלה”: לכל שירות יש בסיס נתונים משלו (בידוד מזימות).

• עסקאות/מאזנים הם יחסי (PostgreSQL) עם אינווריאנטים קפדניים.
• אירועים/יומן - Append-only (קפקא/רדפנדה).
• מטמון/הפעלות - Redis/KeyDB; לוחות ראווה, רדיס סטים מסודרים.
• חיפוש - OpenSearch/Elastic.
• תחזיות קריאה ממומשות (CQRS) - רשימות/דוחות מהירים.

7) מהימנות ויציבות

פסקי זמן/Retry עם jitter/Retry-תקציב רק עבור פעולות אידמפוטנטים.
מפסק מעגל/פליטת חוץ בין שירותים.
מחיצה: בריכות נפרדות עבור ”רועש” במעלה הזרם.
הגבלת קצב ללקוח/מסלול, תרגיל גב (503 + Retry-After).
אות מתה + טיפול בהודעות רעל בתורים.

8) יכולת תצפית

עקבות: OpenTelemetry (”trace _ id” דרך shlyuz = servisy # BD).
מטריצות: RPS, p50/p95/p99, שיעור שגיאה 4xx/5xx, רוויה (CPU/Mem/תור), מטריצות עסקיות (TTP, TtW).
יומנים: JSON מובנה, PII/PAN/IBAN מסווה, מתאם על ידי "trace _ id'.
SLO/התראות: למסלול/פונקציה (לדוגמה, 'הפקדה p95 floth 300 ms', 'הצלחה' 98. 5%`).

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

אפס אמון: MTLS servis↔servis (SPIFFE/SPIRE), תעודות קצרות ימים.
AuthN/Z: OAuth2/JWT (aud/scope/exp), מאפיין דיפרנציאציה של תפקידים.
סודות: KMS/סודות מנהל/סודות אטומים, סבב מפתח.
GDPR/data localization: אשכולות אזוריים, Geo-Signing על שער API.
ביקורת: רישומים בלתי ניתנים לשינוי (תולעת), איתור פעולות ניהול.

10) פריסה ושחרורים

Containers/K8s: שירות אחד = פריסה אחת; משאבים/גבולות; תקציב PodGood.
CI/CD: לינטרים, בדיקות יחידה/חוזה/אינטג, סריקת אבטחה, SBOM.
שחרור: קנרית/כחול ירוק/צל, נדודים מזימה באמצעות הרחבת-וחוזה.
אוטוסקלה: HPA על ידי CPU + RPS + p95 + תור-עומק; לנקז על קריסה.

11) ביצועים ועלות

פרופיל: p95/99 ”על ידי שירותים ושיטות”, גרפי להבה.
מטמון: קריאה דרך/כתיבה דרך; TTL/נכות באירוע.
מיקום נתונים: שמור נתונים חמים קרוב לחישוב.
FinOps: הורד יעד 60-70%, ”בריכות חמות”, הפסקה אוטומטית של עובדים לא פעילים.

12) תבניות דומיין (iGaming)

12. 1 תשלומים/ארנק

שירותים: ”תשלומים-gw” (חזית), ”ארנק”, ”psp-הסתגלות”, ”הונאה-צ 'ק”.
זרם: 'init = reserve = לכידה/rollback' (סאגה).
”Presidated”, ”Advisored Imporated”, ”Diseased/נכשל”.
אידמפוטנטיות: "Idempotency-Key", מת בארנק ".

12. 2 CCM/ציות

”קיק-פלו”, ”מחסן דוק”, ”סנקציות-צ 'ק”, ”בדיקת עידוד”.
”KycRegged/Assed/Responsed”, ”TraxTreasured Updated”.
תור משימה, תיק קו זמן, לאחר פעולות.

12. 3 בונוסים/משימות

שירותים: ”בונוס-מנוע”, ”ארנק-בונוס”, ”זכאות”.
כוריאוגרפיה: 'BettPosed # BettPosed Lought Lought # WalletCredited'.
הגנה מפני התעללות: מענקי אידוי, גבולות, סימולטור חוקים.

12. 4 טורנירים/לוחות מובילים

שירותים: ”טורניר svc”, ”ניקוד”, ”לוח מוביל”.
אחסון: Redis ZSET + ”שוטף” ב ־ OLAP.
”מעודכן”, ”סגור”, ” הוצאה”.

13) חוזה + דוגמה לאירוע (מפושט)

OpenAPI (שבר) - ארנק

yaml paths:
/v1/wallet/{userId}/credit:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreditRequest'
responses:
'202': { description: 'Enqueued' }
components:
schemas:
CreditRequest:
type: object required: [amount, currency, reason, idempotencyKey]
properties:
amount: { type: number }
currency: { type: string, example: UAH }
reason: { type: string, enum: [Deposit, Bonus, Adjustment] }
idempotencyKey: { type: string }

AsyncAPI (שבר) - אירוע

yaml channels:
wallet. credit. applied:
publish:
message:
name: WalletCreditApplied payload:
type: object required: [userId, amount, currency, sourceEventId]

14) בדיקה

יחידה/רכוש מבוסס עבור כללי תחום.
CDC (Pact/Asservable) - בדיקות חוזה של ספק/צרכן.
אינטגרציה עם ברוקרים מקומיים (Testcontainers).

זרימה קריטית E2E (restermatsiya # dpozit = start igry # vyvod)

בדיקות כאוס/כשל: כיבוי PSP/ברוקר ירידה/אובדן אזור.

15) מטריצות ו ־ SLO (מינימום)

זמינות של שירותים: '99. 9% תמורת תשלום/ארנק.
Latency p95: נתיב קריטי API פתיחה 300-500 ms.
תקציב שגיאה: 0. 1–0. 5% לרבעון, כוויות התראות.
תורים: אירועי זמן מובילים (product action), DLQ lock 0. 1%.
עסקים: TTP, TTW, FTD-הצלחה, KYC-TV.

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

עיצוב שירות

[ ] נקו גבולות דומיין ובעל נתונים.

[ ] OpenAPI/ASyncAPI חוזים + סכמות ברישום.

[ ] SLO/התראות מוגדרות; מדדים/שבילים/יומנים בנויים.

[ ] Timeout/Retray/Idempotency Policy.

[ ] סכימה נדודים: להרחיב-ו-חוזה.

לפני השחרור

[ יחידת ]/המרכז לבקרת מחלות/בדיקות אינטגרציה ירוקות.

[ ] הנתיב הקנרי ותוכנית החזרה.

[ ] מסלולי קצב/משקל מוגדרים.

[ ] סודות/מפתחות/תעודות חופרות.

[ ] דגלי פישה וחסידים מוכנים.

17) אנטי דפוסים

רשת כאוטובוס נתונים: שרשראות סינכרוניות עמוקות במקום אירועים.
אלוהים מצוי - די-בי לכל השירותים.
חוסר אידמפוטנטיות * כתיבה כפולה/טקסים.
שחרורים אפלים ללא טלמטריה ומתג-להרוג.
הפעלה נסתרת (דביקות בכל מקום במקום במצב חיצוני).
חוזים ”בקוד” ללא גרסה ומרכז לבקרת מחלות.
לוגיקה בשער API במקום שירותים (שער = דק).

18) Monolith Migration (תאנה חונקת)

1. בחר את שער החזית ואת המעגל הראשי (לדוגמה, תשלומים).
2. הסר רישום בינארי (outbox) ממונולית לאירועים.
3. בהדרגה להעביר נקודות סוף לשירות חדש (ניתוב/משקולות כנריות).
4. לדחוס את המונולית ל ”ליבה” ולכבות אותו.

19) ערימה ותשתית (דוגמה)

תקשורת: REST/gRPC, Kafka/NATS; רישום סכמות.
Repositories: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP - ClickHouse/BigQuery.
מכולות/תזמור: Docker, Kubernetes (Ingress/Gateway), Service Mesh (Istio/Linkerd) במידת הצורך.
שער: שליח/קונג/טראפיק/NGINX.
CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; ברית/OWASP/ZAP.
תצפיות: OpenTelemetry, Prometheus, Tempo/Yager, Loki.

20) גיליון רמאות סופי

עיצוב גבולות על ידי תחום ואחריות נתונים.
סינכרון - רק איפה שצריך תשובה עכשיו; השאר הם אירועים.
חוזים/סכמות/מרכז לבקרת מחלות ביטוח רגרסיה.
Sagas + outbox + idempotency - היסוד של אמינות.
יכולת תצפית ו-SLO אינם אופציה, אלא קריטריון ”מוכן”.
משחרר דרך הקנרית/כחול ירוק, נדידה - להרחיב וחוזה.
בטיחות/ציות: mTLS, JWT, KMS, מידע אזורי.
ראשית, מונולית מודולרית, ואז אבולוציה - אם קנה המידה והצוות מוכנים.