Architektura mikroservice

1) Dlaczego mikroservices w iGaming

Szybkość zmian: niezależne wydania funkcji zespołu (płatności, treść, ryzyko, turnieje).
Niezawodność: awaria jednej usługi nie zmniejsza całego produktu (granice awarii).
Skala: pozioma skala domen „gorących” (portfel, lobby, strumienie).
Zgodność: podział danych według regionu/jurysdykcji.

Kiedy nie warto: mały zespół/tom, brak praktyk DevOps, słaba automatyzacja testów - wtedy modułowy monolit jest lepszy.

2) Domeny, granice i zespoły (DDD + Topologie zespołu)

Kontury domeny: Konto/profil, CCM/Zgodność, Płatności/Portfel, Zawartość gry/Agregacja, Bonusy/Misje, Turnieje, Marketing/CRM, Raportowanie/BI.
Ograniczony kontekst = model danych i umowa językowa.
Zmień przepływ poleceń: jedno polecenie = jedna pętla + jego SLO.
BFF (Backend for Frontend): oddzielne elewacje dla Web/Mobile/Partner, aby nie zbierać „orkiestry” na klienta.

3) Komunikacja: synchroniczny vs asynchroniczny

Synchroniczny (REST/gRPC): gdy potrzebna jest natychmiastowa odpowiedź (sprawdzanie limitów depozytów).
Asynchron (Kafka/NATS/SQS): wydarzenia i procesy tła (memoriałowe cashback, mailingi, aktualizacje ratingu).

• Ścieżka krytyczna = minimalny chmiel sieciowy.
• Integracja między domenami - poprzez zdarzenia i umowne interfejsy API.
• Nie budować „łańcuchy 5 + synchroniczne połączenia” online → używać EDA/sagi.

4) Umowy i wersioning

Umowa pierwsza: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
Kompatybilność SemVer +: Dodawanie pól nie łamie klientów.
Umowy konsumenckie (CDC): automatyczne kontrole w CI (vs. regressions).
Polityka odrzucenia: okno wsparcia (12-18 miesięcy), telemetria dla starszych wersji.

5) Wydarzenia, sagi i spójność

Outbox/Transaction Log Tailing: rekord atomowy „data + event”.

• Orkiestra (koordynator centralny) dla płatności/produktów.
• Choreografia (reakcja na zdarzenia) dla bonusów/misji.
• Idempotence: klucze do 'Id + action + nonce', dedup registry storage.
• Spójność: „zewnętrzne” - poprzez wydarzenia; „wewnętrzne” - transakcje w ramach usługi.

6) Dane i przechowywanie

Zasada „własnego sklepu”: każda usługa posiada własną bazę danych (odizolowanie systemów).

• Transakcje/salda są relacyjne (PostgreSQL) ze ścisłymi niezmiennikami.
• Wydarzenia/dziennik - tylko dodatek (Kafka/Redpanda).
• Pamięć podręczna/sesje - Redis/МDB; liderów - zestawy sortowane Redis.
• Wyszukiwanie - OpenSearch/Elastic.
• Zmaterializowane projekcje odczytu (CQRS) - szybkie listy/raporty.

7) Niezawodność i stabilność

Timeouts/Retry z jitter/Retry-budget tylko dla operacji idempotent.
Wyłącznik-wyłącznik/zewnętrzny-wyrzut między usługami.
Grodzisko: oddzielne baseny do „hałasu” w górę rzeki.
Limity na klienta/trasę, ciśnienie wsteczne (503 + Retry-After).
Trucizna w kolejkach.

8) Obserwowalność

Ślad: OpenTelemetry ('trace _ id' przez shlyuz → servisy → BD).
Wskaźniki: RPS, p50/p95/p99, szybkość błędów 4xx/5xx, nasycenie (CPU/mem/kolejka), wskaźniki biznesowe (TTP, TtW).
Kłody: struktura JSON, maskowanie PII/PAN/IBAN, korelacja przez 'trace _ id'.
SLO/alerty: do trasy/funkcji (na przykład "Deposit p95 ≤ 300 ms", "success ≥ 98. 5%`).

9) Bezpieczeństwo i zgodność

Zero-Trust: mTLS servis اservis (SPIFFE/SPIRE), certyfikaty krótkotrwałe.
AuthN/Z: OAuth2/JWT (aud/scope/exp), atrybut różnicowania ról.
Sekrety: KMS/Secrets Manager/Sealed Secrets, rotacja klucza.
RODO/lokalizacja danych: klastry regionalne, ogrodzenia geograficzne na bramie API.
Audyt: niezmienne dzienniki (WORM), śledzenie działań administratora.

10) Wdrożenie i wydania

Containers/K8s: jedna usługa = jedno uruchomienie; zasoby/limity; Budżet PodDis .
CI/CD: linters, unit/contract/integ tests, security scan, SBOM.
Wydania: kanaryjski/niebiesko-zielony/cień, migracja programu poprzez rozszerzenie i kontrakt.
Autoskale: HPA przez procesor + RPS + p95 + głębokość kolejki; odpływ po upadku.

11) Wydajność i koszt

Profilowanie: p95/99 „według usług i metod”, wykresy płomieni.
Buforowanie: czytanie/zapisywanie; TTL/niepełnosprawność według zdarzeń.
Lokalizacja danych: Przechowywać gorące dane w pobliżu obliczeń.
FinOps: pobierz cel 60-70%, „ciepłe baseny”, auto-pauza nieaktywnych pracowników.

12) Szablony domeny (iGaming)

12. 1 Płatności/Portfel

Usługi: „płatności-gw” (elewacja), „portfel”, „psp-adapters-”, „kontrola oszustw”.
Strumień: 'init → reserve → capture/rollback' (saga).
Сосктий: „początkowe”, „ΔAuthorized”, „Settled/Failed”.
Idempotencja: „Idempotency-Key”, deadup in 'wallet'.

12. 2 CCM/Zgodność

Сервиса: „kyc-flow”, „doc-storage”, „sankcje-check”, „pep-screening”.

Сова тий: "KycSubmitted/Approved/Rejected", ",

Audyt i ETA: kolejka zadań, etap czasowy, działania pooperacyjne.

12. 3 premie/misje

Usługi: „bonus-engine”, „wallet-bonus”, „eligibility”.
Choreografia: 'BetPlaced → BonusEngine → Premia udzielona → WalletCredited'.
Ochrona przed nadużyciami: idempotentne dotacje, limity, symulator reguł.

12. 4 turnieje/tablice liderów

Usługi: „turniej-svc”, „punktacja”, „liderboard”.
Przechowywanie: Redis ZSET + okresowe „spłukiwanie” w OLAP.
Сова тий: „ScoreUpdated”, „TournamentClosed”, „Rez”.

13) Kontrakt + Przykład zdarzenia (uproszczony)

OpenAPI (fragment) - Portfel

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 (fragment) - wydarzenie

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

14) Badanie

Jednostka/nieruchomość dla reguł domeny.
CDC (Pact/Assertible) - dostawca/testy umów konsumenckich.
Integracja z lokalnymi brokerami (Testcontainers).

Krytyczny przepływ E2E (registratsiya → depozit → start igry → vyvod)

Testy chaosu/awaryjnego: zamknięcie PSP/spadek maklera/utrata strefy.

15) Mierniki i SLO (minimum)

Dostępność usług: "≥ 99. 9% 'za płatność/portfel.
Opóźnienie p95: ścieżka krytyczna API ≤ 300-500 ms.
Budżet błędu: 0. 1–0. 5% na kwartał, wpisy oparzeń.
Kolejki: wydarzenia czasu realizacji (produkować → zużyć), DLQ ≤ 0. 1%.
Biznes: TTP, TtW, FTD-sukces, KYC-TtV.

16) Listy kontrolne

Projektowanie usług

• Wyczyść granicę domeny i właściciela danych.
• Kontrakty OpenAPI/AsyncAPI + schematy w rejestrze.
• zdefiniowane SLO/wpisy; mierniki/ścieżki/kłody są wbudowane.
• Polityka dotycząca Timeout/Retray/Idempotency.
• Schemat migracji: rozszerzenie i kontrakt.

Przed zwolnieniem

• Jednostki/CDC/testy integracyjne zielone.
• Plan trasy kanaryjskiej i odwrócenia.
• Wartości graniczne/trasy wagi są skonfigurowane.
• Sekrety/klucze/certyfikaty kopią.
• Przygotowano flagi i pęcherzyki Ficha.

17) Anty-wzory

Sieć jako magistrala danych: głębokie łańcuchy synchroniczne zamiast zdarzeń.
Wspólny „bóg” - DB dla wszystkich usług.
Brak idempotencji → podwójne odpisy/memoriały.
Ciemne uwolnienia bez telemetrii i wyłącznika.
Sesja ukryta (lepkość wszędzie zamiast stanu zewnętrznego).
Umowy „w kodzie” bez wersji i CDC.
Logika w bramce API zamiast usług (brama = cienka).

18) Migracja monolityczna (dusiciel rys)

1. Wybierz bramę fasady i obwód podstawowy (na przykład płatności).
2. Usuń logowanie binarne (outbox) z monolith do zdarzeń.
3. Stopniowe przenoszenie punktów końcowych do nowej usługi (wagi routingu/kanaryjskiej).
4. Skompresować monolit do „rdzenia” i wyłączyć go.

19) Stos i infrastruktura (przykład)

Komunikacja: REST/gRPC, Kafka/NATS; Rejestr schematu.
Repozytoria: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP - ClickHouse/Query.
Kontenery/orkiestra: Docker, Kubernetes (Ingress/Gateway), Service Mesh (Istio/Linkerd) w razie potrzeby.
Brama: Wysłannik/Kong/Traefik/NGINX.

CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; Pakt/OWASP/

Obserwowalność: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) Końcowy arkusz oszustwa

Projektowanie granic według domeny i odpowiedzialności za dane.
Synchron - tylko wtedy, gdy odpowiedź jest teraz potrzebna; Reszta to wydarzenia.
Umowy/Programy/CDC - Ubezpieczenie regresyjne.
Sagas + outbox + idempotency - podstawa niezawodności.
Obserwowalność i SLO nie są opcją, ale „gotowe” kryterium.
Wydania za pośrednictwem kanarka/niebiesko-zielony, migracje - rozszerzyć i kontrakt.
Bezpieczeństwo/zgodność: mTLS, JWT, KMS, dane regionalne.
Najpierw monolit modułowy, potem ewolucja - jeśli skala i zespół są gotowe.