Arhitectura microservice

1) De ce microservicii în iGaming

Viteza schimbării: eliberări independente ale caracteristicilor echipei (plăți, conținut, risc, turnee).
Fiabilitate: eșecul unui serviciu nu reduce întregul produs (limite de eșec).
Scară: scară orizontală a domeniilor „fierbinți” (portofel, lobby, fluxuri).
Conformitate: segregarea datelor pe regiuni/jurisdicții.

Când nu merită: o echipă mică/volum, fără practici DevOps, automatizarea slabă a testelor - atunci un monolit modular este mai bun.

2) Domenii, frontiere și echipe (Topologii DDD + Team)

Contururi de domeniu: Cont/Profil, CCM/Conformitate, Plăți/Portofel, Conținut joc/Agregare, Bonusuri/Misiuni, Turnee, Marketing/CRM, Raportare/BI.
Context delimitat = Model de date și contract de limbă.
Schimbarea fluxurilor ↔ comenzi: o comandă = o buclă + SLO-urile sale.
BFF (Backend for Frontend): fațade separate pentru Web/Mobile/Partner, pentru a nu colecta „orchestrație” pe client.

3) Comunicații: sincron vs asincron

Sincron (REST/gRPC): atunci când este necesar un răspuns imediat (verificarea limitelor de depozit).
Asynchron (Kafka/NATS/SQS): evenimente și procese de fundal (acumulare cashback, corespondență, actualizări de rating).

• Cale critică = hamei minim de rețea.
• Integrarea cross-domain - prin evenimente și API-uri contractuale.
• Nu construiți „lanțuri de apeluri sincrone 5 +” online → utilizați EDA/sagas.

4) Contracte și versioning

Contract unu: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
Compatibilitate SemVer +: Adăugarea de câmpuri nu rupe clienții.
Contracte conduse de consumatori (CDC): controale auto în CI (vs. regresii).
Politica de respingere: fereastră de sprijin (12-18 luni), telemetrie pentru versiunile mai vechi.

5) Evenimente, saga și consecvență

Outbox/Transaction Log Tailing: înregistrare atomică „date + eveniment”.

• Orchestrație (coordonator central) pentru plăți/ieșiri.
• Coregrafie (reacție la evenimente) pentru bonusuri/misiuni.
• Idempotence: taste pe 'entityId + action + nonce', stocare registry dedup.
• Coerență: „extern” - prin evenimente; „intern” - tranzacții în cadrul serviciului.

6) Date și stocare

Principiul „magazinului propriu”: fiecare serviciu deține propria bază de date (izolarea schemelor).

• Tranzacțiile/soldurile sunt relaționale (PostgreSQL) cu invarianți stricți.
• Evenimente/jurnal - numai adăugați (Kafka/Redpanda).
• Cache/sesiuni - Redis/KeyDB; clasamente - Seturi sortate Redis.
• Căutare - OpenSearch/Elastic.
• Proiecții de citire materializate (CQRS) - liste/rapoarte rapide.

7) Fiabilitate și stabilitate

Timeouts/Încercați din nou cu jitter/Retry-buget numai pentru operațiuni idempotente.
Circuit-breaker/Outlier-ejectare între servicii.
Perete etanș: piscine separate pentru „zgomotos” în amonte.
Rate limite per client/traseu, backpressure (503 + Retry-After).
Scrisoarea moartă + manipularea mesajelor otrăvitoare la cozi.

8) Observabilitate

Trace: OpenTelemetry ('trace _ id' prin shlyuz→servisy→BD).
Metrici: RPS, p50/p95/p99, rata de eroare 4xx/5xx, saturație (CPU/mem/coadă), valori de afaceri (TTP, TtW).
Busteni: JSON structurat, mascare PII/PAN/IBAN, corelare prin 'trace _ id'.
SLO/alerte: la traseu/funcție (de exemplu, „Depozit p95 ≤ 300 ms',” succes ≥ 98. 5%`).

9) Siguranță și conformitate

Zero-Trust: mTLS servis↔servis (SPIFFE/SPIRE), certificate de scurtă durată.
AuthN/Z: OAuth2/JWT (aud/scope/exp), atribuie diferențierea rolurilor.
Secretele: KMS/Secrets Manager/Secretele sigilate, rotație cheie.
Localizare GDPR/date: clustere regionale, geo-scrimă pe gateway-ul API.
Audit: busteni imuabili (WORM), urmarirea actiunilor admin.

10) Implementare și versiuni

Containers/K8s: un serviciu = o implementare; resurse/limite; PodDisruptionBudget.
CI/CD: lintere, teste de unitate/contract/integ, scanare de securitate, SBOM.
Versiuni: canar/albastru-verde/umbră, migrarea schemelor prin extindere și contract.
Autoscale: HPA de CPU + RPS + p95 + coadă de adâncime; scurgere pe colaps.

11) Performanță și cost

Profilare: p95/99 „prin servicii și metode”, flacără-grafice.
Caching: citire/scriere; TTL/dizabilitate în funcție de eveniment.
Localitatea de date: Păstrați datele fierbinți aproape de calcul.
FinOps: descărcare țintă 60-70%, „piscine calde”, auto-pauză a lucrătorilor inactivi.

12) Șabloane de domeniu (iGaming)

12. 1 Plăți/Portofel

Servicii: „plăți-gw” (fațadă), „portofel”, „adaptoare psp”, „verificare frauduloasă”.
Stream: „init → reserve → capture/rollback” (saga).
События: 'PaymentInitiated', 'PaymentAuthorized', 'PaymentSettled/Failed'.
Idempotency: 'Idempotency-Key', deadup în 'portofel'.

12. 2 CCM/Conformitate

Сервисы: „kyc-flow”, „doc-storage”, „sancțiuni-check”, „pep-screening”.
События: 'KycTransmis/Aprobat/Respins', 'RiscScorActualizat'.
Audit și ETA: coadă de sarcini, caz de timp, post-acțiuni.

12. 3 Bonusuri/Misiuni

Servicii: 'bonus-engine', 'wallet-bonus', 'eligibilitate'.
Coregrafie: 'BetPlasat → BonusEngine → BonusAcordat → WalletCreditat'.
Protecția împotriva abuzurilor: granturi idempotente, limite, simulator de reguli.

12. 4 Turnee/Clasamente

Servicii: 'turneu-svc', 'notare', 'clasament'.
Stocare: Redis ZSET + periodic „culoare” în OLAP.
События: 'ScoreUpdated', 'TournamentClosed', 'RewardEmissed'.

13) Contract + Eveniment Exemplu (simplificat)

OpenAPI (fragment) - Portofel

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) - eveniment

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

14) Testarea

Unitate/Proprietate bazată pe reguli de domeniu.
CDC (Pact/Assertible) - testele contractuale ale furnizorilor/consumatorilor.
Integrarea cu brokerii locali (Testcontainers).

E2E fluxului critic (registratsiya→depozit→start igry→vyvod)

Chaos/Failover teste: PSP shutdown/broker drop/zona pierdere.

15) Metrics și SLO (minim)

Disponibilitatea serviciilor: '≥99. 9% "pentru plata/portofel.
Latență p95: cale critică API ≤ 300-500 ms.
Bugetul de eroare: 0. 1–0. 5% pe trimestru, alerte de ardere.
Cozi: evenimente în timp de plumb (produce→consume), DLQ ≤ 0. 1%.
Afaceri: TTP, TtW, FTD-succes, KYC-TtV.

16) Liste de verificare

Proiectarea serviciilor

• Ștergeți limitele domeniului și proprietarul datelor.
• OpenAPI/AsyncAPI contracte + scheme în Registry.
• SLO/alerte definite; metrici/trasee/busteni sunt construite în.
• Timeout/Retray/Idempotency Policies.
• Migrarea schemelor: extinderea și contractarea.

Înainte de lansare

• Unitate/CDC/integrare teste verde.
• Traseu canar și plan rollback.
• Sunt configurate rute de limită/greutate.
• Secretele/cheile/certificatele sunt săpate.
• Steaguri Ficha și folback sunt pregătite.

17) Anti-modele

Rețea ca magistrală de date: lanțuri sincrone profunde în loc de evenimente.
Comun „zeu” - DB pentru toate serviciile.
Lipsa idempotenței → dubla scriere/accruals.
Lansări întunecate fără telemetrie şi kill-switch.
Sesiune ascunsă (lipiciozitate peste tot în loc de condiție externă).
Contracte „în cod” fără versiune și CDC.
Logică în gateway-ul API în loc de servicii (gateway = subțire).

18) Migrație Monolit (Strangulator Fig)

1. Selectați poarta de fațadă și circuitul primar (de exemplu, plăți).
2. Eliminați logarea binară (outbox) de la monolit la evenimente.
3. Transferați treptat punctele finale la un nou serviciu (rutare/greutăți canare).
4. Comprimați monolitul la „miez” și opriți-l.

19) Stiva și infrastructura (exemplu)

Comunicații: REST/gRPC, Kafka/NATS; Registrul Schema.
Depozite: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP - ClickHouse/BigQuery.
Containere/orchestrație: Docker, Kubernetes (Ingress/Gateway), Service Mesh (Istio/Linkerd), dacă este necesar.
Gateway: Trimisul/Kong/Traefik/NGINX.
CI/CD: Acțiuni GitHub/CI GitLab + ArgoCD/Flux; Pact/OWASP/ZAP.
Observabilitate: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) Final foaie de ieftin

Proiectarea limitelor în funcție de domeniu și responsabilitatea datelor.
Sincron - numai în cazul în care un răspuns este necesar acum; restul sunt evenimente.
Contracte/Scheme/CDC - Asigurare de regresie.
Sagas + outbox + idempotency - fundamentul fiabilității.
Observabilitatea și SLO nu sunt o opțiune, ci criteriul „gata”.
Lansări prin canar/albastru-verde, migrații - extindere și contract.
Siguranță/conformitate: mTLS, JWT, KMS, date regionale.
În primul rând, un monolit modular, apoi evoluția - dacă scara și echipa sunt gata.