Microservice-Architektur

1) Warum Microservices in iGaming

Änderungsrate: Unabhängige Freigaben von Teams (Zahlungen, Inhalte, Risiko, Turniere).
Zuverlässigkeit: Der Ausfall eines Dienstes bringt nicht das gesamte Produkt zu Fall (Ausfallgrenzen).
Skalierung: horizontaler Scale von „heißen“ Domains (Wallet, Lobby, Streams).
Compliance: Datensegregation nach Regionen/Jurisdiktionen.

Wenn es sich nicht lohnt: kleines Team/Volumen, keine DevOps-Praktiken, schwache Testautomatisierung - dann ist ein modularer Monolith besser.

2) Domains, Grenzen und Teams (DDD + Team Topologies)

Domain-Konturen: Konto/Profil, KUS/Compliance, Zahlungen/Wallet, Spielinhalte/Aggregation, Boni/Missionen, Turniere, Marketing/CRM, Reporting/BI.
Bounded Context = Vertrag über Datenmodell und Sprache.
Änderungsströme ↔ Teams: ein Team = ein Loop + eigene SLOs.
BFF (Backend for Frontend): einzelne Fassaden unter Web/Mobile/Partner, um keine „Orchestrierung“ am Kunden zu sammeln.

3) Kommunikation: synchron vs asynchron

Synchron (REST/gRPC): Wenn eine sofortige Antwort erforderlich ist (Überprüfung der Limits bei der Einzahlung).
Asynhron (Kafka/NATS/SQS): Ereignisse und Hintergrundprozesse (Cashback, Mailings, Ratings aktualisieren).

• Kritischer Pfad = Minimum an Netzwerk-Hops.
• Domänenübergreifende Integration - durch Events und vertragliche APIs.
• Bauen Sie keine „Ketten von 5 + synchronen Anrufen“ online → verwenden Sie EDA/Saga.

4) Verträge und Versionierung

Vertrag: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
SemVer + Kompatibilität: Das Hinzufügen von Feldern stört die Kunden nicht.
Consumer-driven contracts (CDC): Auto-Checks in CI (gegen Regressionen).
Deprecation policy: Support-Fenster (12-18 Monate), Telemetrie nach alten Versionen.

5) Ereignisse, Sagen und Konsistenz

Outbox/Transaction Log Tailing: atomarer Datensatz „Daten + Ereignis“.

• Orchestrierung (zentraler Koordinator) für Zahlungen/Auszahlungen.
• Choreographie (Reaktion auf Ereignisse) für Boni/Missionen.
• Idempotenz: Schlüssel auf 'entityId + action + nonce', Speicherung der Dedup-Registry.
• Konsistenz: „extern“ - durch Ereignisse; „intern“ - Transaktionen innerhalb eines Dienstes.

6) Daten und Speicherung

Prinzip „eigener Stor“: Jeder Dienst besitzt eine eigene DB (Isolation der Schaltungen).

• Transaktionen/Salden - relational (PostgreSQL) mit strengen Invarianten.
• Events/log - nur append (Kafka/Redpanda).
• Cache/Sitzungen - Redis/KeyDB; Leaderboards - Redis Sorted Sets.
• Die Suche ist OpenSearch/Elastic.
• Materialisierte Projektionen zum Lesen (CQRS) - Schnelllisten/Berichte.

7) Zuverlässigkeit und Nachhaltigkeit

Timeouts/Retry mit Jitter/Retry-Budget nur für idempotente Operationen.
Circuit-breaker/Outlier-ejection zwischen den Diensten.
Bulkhead: separate Pools für „laute“ Upstreams.
Rate limits per-client/route, backpressure (503 + Retry-After).
Dead-letter + poison-message handling in Warteschlangen.

8) Beobachtbarkeit (Observability)

Tracing: OpenTelemetry („trace _ id“ durch die shlyuz→servisy→BD).
Metriken: RPS, p50/p95/p99, Fehlerrate 4xx/5xx, Sättigung (CPU/mem/queue), Geschäftsmetriken (TTP, TtW).
Logs: Structural JSON, PII/PAN/IBAN Masking, Coreation nach 'trace _ id'.
SLO/alert: pro Strecke/Funktion (z.B. 'Deposit p95 ≤ 300 ms', 'success ≥ 98. 5%`).

9) Sicherheit und Compliance

Zero-Trust: mTLS servis↔servis (SPIFFE/SPIRE), kurzlebige Zertifikate.
AuthN/Z: OAuth2/JWT (aud/scope/exp), attributive Rollenabgrenzung.
Geheimnisse: KMS/Secrets Manager/Versiegelte Geheimnisse, Schlüsselrotation.
DSGVO/Datenlokalisierung: regionale Cluster, Geo-Fencing am API-Gateway.
Audit: Unveränderliche Protokolle (WORM), Verfolgung von Admin-Aktivitäten.

10) Rollouts und Releases

Container/K8s: ein Service = ein Deploy; Ressourcen/Grenzen; PodDisruptionBudget.
CI/CD: Linters, Unit/Contract/Integ-Tests, Sicherheitsscan, SBOM.
Releases: canary/blue-green/shadow, Migration von Schemata über Expand-and-Contract.
Autoscale: HPA durch CPU + RPS + p95 + queue-depth; drain beim Minimieren.

11) Leistung und Kosten

Profiling: p95/99 „nach Dienstleistungen und Methoden“, Flame-Graphen.
Caching: read-through/write-through; TTL/Behinderung durch Veranstaltungen.
Datenlokalität: Halten Sie heiße Daten nahe an der Berechnung.
FinOps: Download-Ziel 60-70%, „warme Pools“, Auto-Pause inaktive Worker.

12) Domain-Vorlagen (iGaming)

12. 1 Zahlungen/Wallet

Dienstleistungen: 'payments-gw' (Fassade), 'wallet', 'psp-adapters-', 'fraud-check'.

Init → Reserve → Capture/Rollback (Saga)

События: `PaymentInitiated`, `PaymentAuthorized`, `PaymentSettled/Failed`.
Idempotenz: 'Idempotency-Key', dedup in 'wallet'.

12. 2 KUS/Compliance

Сервисы: `kyc-flow`, `doc-storage`, `sanctions-check`, `pep-screening`.
События: `KycSubmitted/Approved/Rejected`, `RiskScoreUpdated`.
Audit und ETA: Aufgaben-Warteschlange, Fall-Timeline, Post-Aktionen.

12. 3 Boni/Missionen

Dienstleistungen: 'bonus-engine', 'wallet-bonus', 'eligibility'.

BetPlaced → BonusEngine → BonusGranted → WalletCredited

Schutz vor Missbrauch: idempotente Zuschüsse, Limits, Regelsimulator.

12. 4 Turniere/Leaderboards

Dienstleistungen: 'tournament-svc', 'scoring', 'leaderboard'.
Speicherung: Redis ZSET + periodisches „Brummen“ im OLAP.
События: `ScoreUpdated`, `TournamentClosed`, `RewardIssued`.

13) Beispiel „Vertrag + Ereignis“ (vereinfacht)

OpenAPI (Fragment) - Wallet

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 (Snippet) - Ereignis

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

14) Testen

Unit/Property-based für Domänenregeln.
CDC (Pact/Assertible) - Vertragstests von Anbietern/Verbrauchern.
Integration mit lokalen Brokern (Testcontainern).

E2E kritische Flows (registratsiya→depozit→start igry→vyvod)

Chaos/Failover-Tests: PSP deaktivieren/Broker fallen/Zone verlieren.

15) Metriken und SLO (Minimum)

Verfügbarkeit: '≥99. 9% 'für Zahlung/Wallet.

Latency p95: Kritische Pfad-API ≤ 300-500 ms

Error budget: 0. 1–0. 5% pro Quartal, burn-alerts.
Warteschlangen: Lead Time Events (produce→consume), DLQ ≤ 0. 1%.
Unternehmen: TTP, TtW, FTD-Erfolg, KYC-TtV.

16) Checklisten

Service-Design

• Klare Domänengrenze und Dateneigentümer.
• OpenAPI/AsyncAPI + Schema Verträge in der Registry.
• SLO/Warnmeldungen sind definiert; Metriken/Traces/Logs sind eingebettet.
• Zeit-/Retray-/Idempotenz-Richtlinien.
• Schema-Migrationen: expand-and-contract.

Vor der Veröffentlichung

• Unit/CDC/Integrationstests grün.
• Kanarische Route und Rollback-Plan.
• Rate-limits/weight Routen sind konfiguriert.
• Geheimnisse/Schlüssel/Zertifikate werden gewürfelt.
• Ficha-Flaggen und Vollbacks sind vorbereitet.

17) Anti-Muster

Das Netzwerk als Datenbus: tiefe synchrone Ketten statt Events.
Ein gemeinsamer „Gott“ -BD für alle Dienste.
Keine Idempotenz → doppelte Abschreibungen/Gebühren.
Dark Releases ohne Telemetrie und Kill-Switch.
Versteckte Sitzung (Klebrigkeit überall anstelle eines äußeren Zustands).
Verträge „im Code“ ohne Version und CDC.
Logik im API-Gateway statt Services (Gateway = thin).

18) Migration vom Monolithen (Strangler Fig)

1. Markieren Sie die Gateway-Fassade und den Primärkreis (z. B. Zahlungen).
2. Entfernen Sie die binäre Logik (outbox) vom Monolithen zu den Ereignissen.
3. Schrittweise Umstellung der Endpunkte auf den neuen Service (Routing/Kanariengewichte).
4. Komprimieren Sie den Monolith zu einem „Kern“ und deaktivieren Sie ihn.

19) Stack und Infrastruktur (Beispiel)

Mitteilungen: REST/gRPC, Kafka/NATS; Schema Registry.
Speicher: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP — ClickHouse/BigQuery.
Container/Orchestrierung: Docker, Kubernetes (Ingress/Gateway), Service Mesh (Istio/Linkerd) bei Bedarf.
Gateway: Envoy/Kong/Traefik/NGINX.
CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; Pact/OWASP/ZAP.
Observability: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) Abschließender Spickzettel

Gestalten Sie Grenzen nach Domänen und Datenverantwortung.
Synchron - nur dort, wo jetzt eine Antwort benötigt wird; Der Rest sind Ereignisse.
Verträge/Regelungen/CDC - Regressionsversicherung.
Saga + Outbox + Idempotenz ist die Grundlage für Zuverlässigkeit.
Beobachtbarkeit und SLO sind keine Option, sondern das Kriterium „fertig“.
Freigaben über Canary/Blue-Green, Migrationen - Expand-and-Contract.
Sicherheit/Compliance: mTLS, JWT, KMS, regionale Daten.
Erst der modulare Monolith, dann die Evolution - wenn Maßstab und Team bereit sind.