GH GambleHub

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`.
Tövsiyələr:
'domain' açar sxemini standartlaşdırın. subdomain. verb. status` (snakedot case - vahid).
Əlaqə azaltın - bir mübadilə → bir çox növbə, ehtiyac olmadan «çox mübadilə» deyil.
Multi-tenantlıq üçün: müştəriyə vhost/namespace, açar prefiksləri: 'tenantX. payments. psp…`.

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.

Mini-siyasət (konsepsiya):
  • `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.

Sifariş:
  • 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. #`
Sıra-istehlakçılar:
  • `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.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

Telegram
@Gamble_GC
İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.