GH GambleHub

Hadisə arxitekturası

Hadisə arxitekturası (EDA)

1) Hadisə nədir və niyə EDA

Hadisə - artıq domendə («PlayerVerified», «PaymentCaptured») baş vermiş dəyişməz faktdır. EDA bu faktların və onlara reaksiyaların dərc ətrafında inteqrasiya qurur:
  • xidmətlərin zəif əlaqəsi,
  • müstəqil istehlakçı miqyası,
  • replay/proyeksiyaların yenidən qurulması,
  • şəffaf audit.

EDA sinxron API-ləri ləğv etmir - asenxron təbəqəyə xaç xidməti asılılıqlarını çıxararaq onları tamamlayır.


2) Hadisə növləri

Domen: əhəmiyyətli biznes faktları (OrderPlaced, BonusGranted).
İnteqrasiya: xarici sistemlər üçün «şəkillər «/dəyişikliklər (UserUpdated, WalletBalanceChanged).
Texniki: həyat dövrü və telemetriya (Heartbeat, PipelineFailed).
Əmrlər (hadisə deyil, yaxınlıqda): «X» (CapturePayment) təlimatları.

Tövsiyə: domen hadisələri - ilkin; inteqrasiya xüsusi istehlakçılar üçün proyeksiyalar tərəfindən formalaşır.


3) Hadisə müqavilələri və sxemlər

Схема: Avro/Protobuf/JSON Schema + Schema Registry; Uyğunluq strategiyası: «BACKWARD» istehlakçıların təkamülü üçün, «FULL» kritik mövzularda.
CloudEvents (id, source, type, time, subject, datacontenttype) - vahid başlıqlar.
Məcburi meta məlumat: 'event _ id' (ULID/UUID), 'occurred _ at', 'producer', 'schema _ version', 'correlation _ id '/' causation _ id', 'idempotency _ key'.
Version: add-only sahələr, ad/semantik qırılma qadağan; yeni tiplər - yeni mövzular/tiplər.

Nümunə (Avro, fraqment):
json
{
"type":"record","name":"PaymentCaptured","namespace":"events.v1",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"payment_id","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":"string"},
{"name":"player_id","type":"string"}
]
}

4) Çatdırılma, sifariş və uyğunluq

At-least-once bir defolt kimi → prosessorların idempotentliyi lazımdır.
Sifariş: Partiya (Kafka) və ya növbə (RabbitMQ) daxilində zəmanət verilir, lakin retralar zamanı pozula bilər; hadisə açarı domen qranulunu (məsələn, 'player _ id') əks etdirməlidir.
Uyğunluq: pul/kreditlər üçün - yalnız jurnallar/dastanlar/kompensasiyalar vasitəsilə; LWW-dən çəkinin.

Oxu modeli: proyeksiyalar və caches eventual ola bilər - «yeniləmə gedir»... göstərin və ciddi yollar üçün RNOT strategiyalarından istifadə edin.


5) Outbox/Inbox и CDC

Outbox: Xidmət onun DB faktını yazır və bir əməliyyatda outbox cədvəlində → vorker şində dərc edir.
Inbox: İstehlakçı «event _ id» dedup üçün emal nəticəsi ilə saxlayır.
CDC (Change Data Capture): Tətbiq dəyişikliyi olmadan inteqrasiyalar qurmaq üçün DB-dən (binlog/WAL) şinə dəyişiklik axını.
Idempotency: 'idempotency _ key '/' event _ id' emalı, fiksasiya qədər xarici dünyanı dəyişməyin.


6) CQRS и Event Sourcing

CQRS: write modeli və read-proyeksiyaları paylaşın; proyeksiyalar hadisələrdən ibarətdir və geridə qala bilər.
Event Sourcing: aqreqatın vəziyyəti = onun hadisələrinin yığılması. Üstünlüklər: tam audit/replay; mənfi cəhətləri: miqrasiyaların/sxemlərin/snapshotların mürəkkəbliyi.
Təcrübə: ES - hər yerdə deyil, tarix və kompensasiyanın vacib olduğu yerlərdə; CQRS - demək olar ki, həmişə EDA.


7) Dastanlar: orkestr və xoreoqrafiya

Orkestr: koordinator komandalar göndərir və cavab tədbirlərini gözləyir; mürəkkəb proseslər üçün əlverişlidir (KYC → Deposit → Bonus).
Xoreoqrafiya: xidmətlər bir-birinin hadisələrinə reaksiya verir; asan, lakin izləmək daha çətindir.
Həmişə kompensasiya və addımların müddəti müəyyən edin.


8) Topologiyaların layihələndirilməsi (Kafka/RabbitMQ)

Kafka

Top per domen hadisəsi: 'payments. captured. v1`, `players. verified. v1`.
Partizan açarı: 'player _ id '/' wallet _ id' - sifarişin vacib olduğu yerdə.
`replication. factor=3`, `min. insync. replicas = 2 ', prodüser' acks = all '.
Retention: vaxt (məsələn, 7-90 gün) və/və ya compaction (açar üzrə son vəziyyət).
backoff ilə retry və DLQ üçün topics.

RabbitMQ

Exchanges: `topic`/`direct`, routing key `payments. captured. v1`.
Geniş fan-out üçün - 'topic' + bir neçə sıra; RPC/komandalar üçün - ayrı-ayrı növbələr.
HA üçün Quorum Queues; TTL + retrains üçün dead-letter exchange.


9) Müşahidə və SLO EDA

SLI/SLO:
  • End-to-end latency (occurred_at → emal): p50/p95/p99.
  • Lag/age: istehlakçı geriliyi (Kafka consumer lag, Rabbit backlog age).
  • Throughput nəşr/emal.
  • DLQ-rate və təkrar payı.
  • Biznes əməliyyatlarının uğuru (məsələn, «depozit 5s ≤ təsdiq edilmişdir»).
Təcrübələr:
  • 'trace _ id '/' correlation _ id' (OTel) vasitəsilə hadisələrin korrelyasiyası.
  • Metrik → trek nümunələri (exemplars).
  • Dashboard «Producer → Broker → Consumer» ilə burn-rate alerts.

10) Replay, retenshn və backfill

Proyeksiyaların yenidən qurulması/nasazlıqların düzəldilməsi üçün replay: Yeni proyeksiyaya/neyspace sürün, sonra oxunuşu dəyişdirin.
Retenshn: hüquqi/biznes tələbləri (GDPR/PCI); həssas sahələr - şifrələyin və/və ya tokenləşdirin.
Backfill: birdəfəlik mövzular/növbələr, aydın RPS limitləri, məhsulu boğmamaq üçün.


11) Təhlükəsizlik və uyğunluq

TLS in-tranzit, mTLS daxili müştərilər üçün.
Avtorizasiya: per-topic/per-exchange ACL; namespace/vhost vasitəsilə multitenancy.
PII: hadisədə sahələri minimuma endirmək; envelope metadata ayrıca, faydalı yük lazım olduqda şifrələmək.
Hadisələrə giriş auditi, «hər şeyə qadağa» açarları.
Retenshn siyasəti və silmə hüququ (GDPR): ya məlumat bağlantıları saxlayın, ya da tombstone hadisələri və projeksiyalarda silmə.


12) EDA-da test

Contract tests: istehlakçılar sxemlərin gözləntilərini (consumer-driven) təsdiqləyirlər.
Replay Tests: yeni prosessor/sxem versiyası vasitəsilə tarixi nümunə qaçış.
Chaos ssenariləri: broker gecikməsi/itkisi, düyünlərin düşməsi, istehlakçı gecikməsi → SLO çərçivəsində qalır.
CI-də Smoke: müvəqqəti mövzularda qısa son-end paypline.


13) Miqrasiya «CRUD-inteqrasiya → EDA»

1. Domen faktlarını müəyyən edin.
2. Outbox-u ilkin xidmətlərə daxil edin.
3. Minimum domen hadisələrini dərc edin və 1-2 proyeksiyanı birləşdirin.
4. Sinxron inteqrasiyaları abunələrlə əvəz edərək tədricən söndürün.
5. Schema Registry və uyğunluq siyasətini daxil edin.
6. Hadisələri add-only sahələrlə genişləndirin; sındırma - yalnız yeni növləri vasitəsilə.


14) Anti-nümunələr

Hadisələr = «DTO API» (çox yağlı, daxili modeldən asılıdır) - istehlakçıları pozur.
Schema Registry və uyğunluq olmaması - «kövrək» inteqrasiya.
Koddan nəşr və DB-yə yazmaq atomar deyil (no outbox) - hadisələri itirin.
«Hər yerdə Exactly-once» - faydasız yüksək qiymət; daha yaxşı at-least-once + idempotentlik.
Bir «universal» partizan açarı → isti partizan.
Düz proyeksiyaya replay - onlayn SLO-ları sındırır.


15) Giriş çek siyahısı (0-45 gün)

0-10 gün

Domen hadisələrini və onların açarlarını (sifariş qranulları) müəyyən edin.
Schema Registry-ni genişləndirin və uyğunluq strategiyasını təsdiq edin.
1-2 xidmət outbox/inbox əlavə edin; minimum CloudEvents-envelope.

11-25 gün

retry/DLQ, backoff, empotent prosessorları daxil edin.
Daşbordlar: lag/age/end-to-end; burn-rate alert.
Hadisələrin sənədləşdirilməsi (kataloq), owner's və sxemlərin review prosesləri.

26-45 gün

Birinci proyeksiyanın replay/yenidən qurulması; runbook replay və backfill.
Təhlükəsizlik siyasəti (TLS, ACL, PII), retenshn, GDPR prosedurları.
Broker və istehlakçılar üçün müntəzəm chaos və game-days.


16) Yetkinlik metrikası

100% domen hadisələri sxemlərlə təsvir olunur və qeydiyyata alınır.
Outbox/inbox bütün prodüserlər/ Tier-0/1.
SLO: p95 end-to-end latency və 99% ≥ hədəfləri daxilində consumer lag.
Replay/Backfill downtime olmadan həyata keçirilir; yoxlanılmış runbook var.
Version: yeni sahələr - qırılmadan; köhnə istehlakçılar düşmür.
Təhlükəsizlik: TLS + mTLS, ACL per topic, giriş jurnalları, PII/retenshn siyasəti.


17) Mini snippet

Kafka Producer (etibarlı nəşr, fikirlər):
properties acks=all enable.idempotence=true max.in.flight.requests.per.connection=1 compression.type=zstd linger.ms=5
Consumer prosessor (idempotentlik, psevdokod):
python if inbox.contains(event_id): return # дедуп process(event)            # побочные эффекты детерминированы inbox.commit(event_id)        # atomically with side-effect commit_offset()
DLX (ideya) vasitəsilə RabbitMQ Retry:
  • `queue: tasks` → on nack → DLX `tasks. retry. 1m '(TTL = 60s) → qaytarılması' tasks '; sonra '5m/15m'.

18) Nəticə

EDA inteqrasiyanı dəqiq müqavilələr və idarə olunan uyğunluq ilə biznes faktlarının axınına çevirir. Təməl qurun: sxemlər + reyestr, outbox/inbox, sifariş açarları, idempotent prosessorları, SLO və müşahidə, təhlükəsiz retenshn və replay. Sonra hadisələr miqyaslı, analitik və yeni sahələr üçün «həqiqət mənbəyi» olacaq - kövrək əlaqələr və gecə miqrasiyaları olmadan.

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!

İ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.