Message Broker və hadisələrin marşrutlaşdırılması
(Bölmə: Texnologiya və Infrastruktur)
Qısa xülasə
Message Broker - iGaming-də inteqrasiya və hadisə şininin əsas qatıdır. Mikroservislər, ödənişlər, antifrod, KYC, CRM və analitiklər arasında mesajların çatdırılması, tamponlanması və marşrutlaşdırılmasını həyata keçirir. Düzgün dizayn edilmiş mübadilə (exchanges), növbələr, marşrut açarları və təkrar çatdırılma qaydaları aşağı gecikmə, trafik dalğalanmalarına qarşı müqavimət və proqnozlaşdırıla bilən SLO təmin edir.
iGaming platformasında brokerin rolu
Services Decupling: sərt sinxron zənglərin əvəzinə hadisələrin yayımlanması.
Çevik marşrutlaşdırma: bir tədbir → bir çox istehlakçı (CRM, risk, analitik).
Yük nəzarəti: növbələr, prefetch/QoS, backpresher.
Etibarlılıq və bərpa: təsdiqlər, retralar, DLQ, replikasiya.
Audit və uyğunluq: hadisələrin izlənməsi, PII maskalanması, saxlama siyasəti.
Mesajlaşma modelləri
Point-to-Point (tapşırıq növbəsi): bir istehlakçı tapşırığı (KYC, e-mail, PSP webhook) emal edir.
Pub/Sub (domen hadisələri): bir neçə mərhələdə fan-out mübadiləsində dərc.
Broker vasitəsilə RPC: korrelyasiya ilə sorğu/cavab (nadir hallarda «isti» yollarda, lakin inteqrasiya üçün faydalıdır).
Marşrutlaşdırma konsepsiyaları (AMQP klassikası)
Exchanges və bindings mesajın hansı növbəyə düşəcəyini müəyyənləşdirir:1. direct - 'routing _ key' üçün dəqiq uyğunluq.
2. topic - 'a şablonları. b. c 's "(bir söz) və '#' (0 + söz). Universal seçim.
3. fanout - bütün əlaqəli növbələr üçün geniş yayım.
4. headers - başlıq marşrutu (açar/qiymət), mürəkkəb siyasətlər üçün faydalıdır.
Açar və topologiyaların nümunələri:- `payments. psp. stripe. succeeded`, `payments. psp..failed`, `bets. live. #`, `rg. limit. breach`.
- Domen dəyişdiriciləri: 'payments. topic`, `bets. topic`, `risk. topic`; ayrı - sistem hadisələri üçün 'platform. audit`.
Növbələr və siyasətlər
İş növbəsi: biznes hendlerlər tərəfindən istehlak edilir.
Retry-növbələr: TTL (delay) və DLX ilə eksponent backoflar üçün (məsələn, '5s → 1m → 5m → 1h').
DLQ (Dead-Letter Queue): retrayların tükənməsindən sonra son «zibil».
Priorities: təcili tapşırıqlar üçün (nəticələr> məktublar).
Lazy/Quorum: lazy - böyük backlogs ilə RAM qənaət; quorum - konsensus əsasında HA.
- `work. q` → `x-dead-letter-exchange=retry. ex`
- `retry. 1m. q` → `x-message-ttl=60000`, `x-dead-letter-exchange=work. ex`
- `dlq. q '→ monitorinq və əl remediasiya
Çatdırılma zəmanəti və qaydası
At-least-once - defolt: dublikatlar mümkündür → idempotentlik tələb olunur.
At-most-once - minimum gecikmə, lakin itki riski («kritik olmayan» siqnallar üçün).
Exactly-once - nadir hallarda brokerlərdə praktik; daha çətin və daha bahalı əldə edilir. Pul üçün: at-least-once + sərt idempotentlik.
- Bir növbədə və tək istehlakçıda nizam saxlanılır; paralelizmdə + retralarda nizam pozula bilər.
- Sifariş tələbi olan varlıqlar üçün - axını seriallaşdırın (açar üçün tək-aktiv istifadəçi) və ya «yuva» şinlərinə köçürün (axın).
İdempotentlik və əməliyyat nəşri
Mesajda Idempotency-Key (ULID/UUID), TTL və ya açar upsert ilə depolama.
Outbox-pattern: bir iş əməliyyatının bir hissəsi olaraq «outbox» cədvəlinə hadisənin yazılması, bağlayıcı broker dərc → «ikiqat qeyd »/itki istisna edir.
Korrelyasiya meta məlumatları: 'message _ id', 'trace _ id', 'causation _ id', 'tenant _ id'.
Broker vasitəsilə RPC (lazım olduqda)
Sorğu 'reply _ to' və 'correlation _ id' ilə dərc olunur, cavab göstərilən növbədədir.
Məhdud istifadə edin (xarici provayderlər, sinxron yoxlamalar), fasilələrə və chat tendensiyasına nəzarət edin (əks halda - paylanmış monolitə deqradasiya).
İsti istifadəçi yolları üçün asenkron hadisələr + vəziyyət proyeksiyaları üstünlük verilir.
Məlumat müqavilələri və sxemlər
Formatlar: Avro/Protobuf/JSON-Schema. JSON üçün - versiya və məcburi sahələri qeyd edin.
Təkamül siyasəti: backward-compatible dəyişikliklər; miqrasiya olmadan pozucu dəyişikliklər qadağandır.
PII - sahələrin tokenlaşdırılması/şifrələnməsi; təyinatı (purpose) və saxlama müddəti.
Səhv emalı, retralar, DLQ
Təsnifat: müvəqqəti (şəbəkə/5xx) → retralar; validasiya/sxem → DLQ.
Exponential backoff + jitter, cəhdlərin sayının məhdudlaşdırılması, «poison-pill» işarələri.
Gecikmiş çatdırılma: TTL/Delayed-exchange vasitəsilə.
DLQ-dən «Reinject Work» aləti səbəb fiksindən sonra.
Müşahidə və SLO
Prodüser metrikası: nəşr sürəti, səhvlər/təsdiqlər.
Növbələrin metrikası: uzunluğu, istehlak sürəti, retras faizi, p99 növbə vaxtı.
Konsumerlər: lag, throughput, emal vaxtı, NACK payı.
SLO: p99 E2E-gizli çatdırılma hadisə ≤ X saniyə; mövcudluğu ≥ 99. 9%; DLQ-rate ≤ Y%.
Trace: keçici 'trace _ id '/' span _ id', log 'message _ id'.
Alertlər: DLQ/lag artımı, kvorum azalması, NACK artımı, retry-mərhələlərinin «yapışması».
Təhlükəsizlik və Access
tranzit TLS/MTLS; sabit növbələri saxlayarkən diskdə şifrələmə.
RBAC/ACL: vhost/namespace/topika ilə publish/consume hüquqları.
Seqmentasiya: həssas domenlər (ödənişlər/KUS) - fərdi mübadilə/klasterlər.
Vault/SOPS sirləri; audit-log nəşrlər/abunələr.
Məlumatların lokallaşdırılması: regionlar üzrə saxlama və retenşn (AB, Türkiyə, LatAm).
Yüksək mövcudluq və DR
Kvorum növbələri/replikasiyası, tək sayda node, AZ anti-affiniti.
Kritik domenlər üçün regionlararası replikasiya (federation/shovel).
Keçid qaydaları (runbook), dövri DR təlimləri (game day).
Kod kimi topologiyaların versiyası (IaC) - təkrarlanan deploi və sürətli resink.
Performans və sazlama
Prodüser: batch-təsdiqlər (publisher confirms), kanalların təkrar istifadəsi, asenxron nəşrlər.
Növbələr: orta vəzifə müddəti altında prefetch; lazy dərin backlogs üçün; «qaynar» növbələrin nod ilə yayılması.
Şəbəkə/OS: 10/25G, file descriptors, TCP-sazlama. JVM/GC - yük profili altında.
Burst-yük testləri (matçlar, turnirlər, pik ödənişlər).
iGaming üçün standart marşrut nümunələri
1. Ödəniş hadisələri (topic):
Exchange: `payments. topic`
Keys:- `payments. psp. stripe. succeeded`
- `payments. psp..failed`
- `withdrawal. requested. #`
- `ledger. writer. q '(bind:' payments. #`)
- `crm. triggers. q '(bind:' payments... succeeded ')
- `risk. reviews. q '(bind:' withdrawal. #`)
2. Anti-skorinq (direct + retry):
`risk. work. q` ← `risk. direct` (`routing_key=risk. check`)
`risk. retry. 1m. q '(TTL 60s → DLX geri' risk. direct`)
`risk. dlq. q 'ölümcül üçün.
3. Notifikasiyalar (fanout + prioritet):
`notify. fanout` → `email. q (prio)`, `sms. q`, `push. q`
Prioritetlər: marketinq poçtlarından yuxarı nəticələr/limitlər.
4. Audit və izləmə (headers):
Başlıqlar '{«tenant «: «X ««, critical»:» true»} '→ ayrıca audit növbəsi.
Minimum mesaj sxeminin nümunəsi (JSON)
json
{
"message_id": "01HX8H8Y6D6W0T1S2A3B4C5D6E",
"trace_id": "f4d2a1...e9",
"occurred_at": "2025-11-05T11:20:45. 321Z",
"tenant_id": "eu-1",
"schema_version": 3,
"event": "payments. psp. stripe. succeeded",
"payload": {
"payment_id": "pay_123",
"player_id": "p_987",
"amount": { "currency": "EUR", "value": 50. 00 },
"psp_tx": "tx_456",
"idempotency_key": "ulid_..."
}
}
Digər konturlarla inteqrasiya
Streaming/analitika: əhəmiyyətli mövzular retenshn və reprocessing üçün lot şin (Kafka/Redpanda) dublyaj edilə bilər.
Fichestor: hadisələr → onlayn fiçlər (Redis) və oflayn partiyalar (Parquet/OLAP).
Saga orkestrasiyası: direct/topic vasitəsilə komandalar, hadisələr - pub/sub; kompensasiya addımlar - ayrı-ayrı mesajlar kimi.
Giriş çek siyahısı
1. Domen dəyişdiriciləri və marşrut açarları standartını təyin edin.
2. Hər kritik axın üçün work/retry/DLQ dizayn edin.
3. publisher confirms, 'prefetch', prioritetlər və lazımi yerlərdə delay daxil edin.
4. idempotency-key, outbox və korrelyasiya ID daxil edin.
5. Məlumat sxemlərini və təkamül qaydalarını təsdiq edin.
6. TLS/RBAC, domen/tenant seqmentini konfiqurasiya edin.
7. SLO və alertlər (lag, DLQ-rate, p99).
8. DR planı və avtomatlaşdırılmış IaC topologiyaları hazırlayın.
9. Yükləmə və chaos testləri aparın.
10. DLQ-dən hadisələr və re-inject üçün runbook sənədləşdirin.
Antipatternlər
Açar nizam-intizamı olmadan bir «nəhəng» mübadilə; təsadüfi bindinqlər «lazım olduğu kimi».
Heç bir retry/DLQ və müvəqqəti/ölümcül səhvlərin qarışması.
Sinxron RPC istifadəçinin isti yollarda broker üzərində.
İdempotentlik və outbox → dubl/pul itkisi yoxdur.
PII açıq saxlama, hər kəs üçün publish/consume paylaşımı.
Nəticələr
Yaxşı dizayn edilmiş Message Broker, marşrutun proqnozlaşdırıla biləcəyi və pozulma müqavimətinin topologiya səviyyəsində qurulduğu etibarlı bir hadisə arteriyasıdır. Hər bir kritik axın, idempotent və outbox, ciddi SLO və müşahidə üçün topic mübadiləsi, vahid standart açarları, work/retry/DLQ istifadə edin. Axın şini və vəziyyət proyeksiyaları ilə tandemdə bu, iGaming platformasına davamlı sürət, şəffaflıq və yük artdıqca mürəkkəbliyə nəzarət edir.