Architecture microservices

1) Pourquoi les microservices dans iGaming

Taux de changement : versions indépendantes des équipes (paiements, contenu, risques, tournois).
Fiabilité : une défaillance d'un service ne gâche pas tout le produit (limites de défaillance).
Échelle : skale horizontal des domaines « chauds » (portefeuille, lobby, strim).
Conformité : ségrégation des données par région/juridiction.

Quand ça ne vaut pas la peine : petite équipe/volume, pas de pratique DevOps, faible automatisation des tests - alors le monolithe modulaire est meilleur.

2) Domaines, frontières et équipes (DDD + Team Topologies)

Contours de domaine : Compte/Profil, CUS/Conformité, Paiements/Portefeuille, Contenu de jeu/Agrégation, Bonus/Missions, Tournois, Marketing/CRM, Reporting/BI.
Bounded Context = contrat de modèle de données et de langage.
Flux de modifications ↔ commandes : une commande = une boucle + son SLO.
BFF (Backend for Frontend) : façades séparées sous Web/Mobile/Partner afin de ne pas assembler une « orchestration » sur le client.

3) Communications : Synchron vs asynchron

Synchron (REST/gRPC) : lorsque vous avez besoin d'une réponse immédiate (vérification des limites au dépôt).
Asynchron (Kafka/NATS/SQS) : événements et processus d'arrière-plan (mise à jour du cashback, envoi, mise à jour des classements).

• Chemin critique = minimum de hops réseau.
• Intégration inter-domaines - par le biais d'événements et d'API contractuelles.
• Ne pas construire des « chaînes d'appels synchrones 5 + » en ligne → utiliser EDA/saga.

4) Contrats et versioning

Premier contrat : OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
BouVer + compatibilité : l'ajout de champs ne brise pas les clients.
Contrats consommateurs-conducteurs (CDC) : Essais de véhicules en IC (contre les régressions).
Politique de déprécation : fenêtre de support (12-18 mois), télémétrie selon les anciennes versions.

5) Événements, sagas et consistance

Outbox/Transaction Log Tailing : enregistrement atomique « données + événement ».

• Orchestration (coordinateur central) pour les paiements/retraits.
• Chorégraphie (réaction aux événements) pour les bonus/missions.
• Idempotence : clés sur 'entityId + action + nonce', stockage du registre dedup.
• Consistance : « externe » - à travers les événements ; « interne » - transactions au sein du service.

6) Données et stockage

Le principe du « store » : chaque service possède sa propre base de données (isolation des circuits).

• Transactions/bilans - relationnels (PostgreSQL) avec des invariants stricts.
• Événements/logs - append-only (Kafka/Redpanda).
• Cache/sessions - Redis/KeyDB ; les leaders sont les Redis Sorted Sets.
• La recherche est OpenSearch/Elastic.
• Projections matérialisées en lecture (CQRS) - Listes/rapports rapides.

7) Fiabilité et durabilité

Timeouts/Retry with jitter/Retry-budget uniquement pour les opérations idempotent.
Circuit-breaker/Outlier-ejection entre les services.
Bulkhead : pools séparés sur les apstrymes « bruyants ».
Rate limits per-client/route, backpressure (503 + Retry-After).
Dead-letter + poison-message handling dans les files d'attente.

8) Observabilité (Observabilité)

Trace : OpenTelemetry ('trace _ id' à travers le shlyuz→servisy→BD).
Métriques : RPS, p50/p95/p99, error rate 4xx/5xx, saturation (CPU/mem/queue), métriques d'entreprise (TTP, TtW).
Logs : JSON structural, masque PII/PAN/IBAN, corelation par 'trace _ id'.
SLO/alertes : par route/fonction (par exemple, 'Deposit p95 ≤ 300 ms', 'success ≥ 98. 5%`).

9) Sécurité et conformité

Zero-Trust : mTLS servis↔servis (SPIFFE/SPIRE), certificats à courte durée de vie.
AuthN/Z : OAuth2/JWT (aud/scope/bou), délimitation attributaire des rôles.
Secrets : KMS/Secret Manager/Sealed Secrets, rotation des clés.
GDPR/localisation de données : clusters régionaux, géofencing sur une passerelle API.
Audit : journaux immuables (WORM), suivi des actions admin.

10) Déploiement et release

Conteneurs/K8s : un service = un deploy ; ressources/limites ; PodDisruptionBudget.
CI/CD : linters, unit/contract/integ-tests, scan de sécurité, SBOM.
Sorties : canary/blue-green/shadow, migration de schémas via expand-and-contract.
Skale automatique : HPA par CPU + RPS + p95 + queue-depth ; drain lors du retrait.

11) Productivité et coût

Profilage : p95/99 « par services et méthodes », graphiques flame.
Cache : read-through/write-through ; TTL/invalidité par événement.
Localisation des données : garder les données chaudes près du calcul.
FinOps : target de téléchargement 60-70 %, « warm pools », auto-pause des workers inactifs.

12) Modèles de domaine (iGaming)

12. 1 Paiements/Portefeuille

Services : 'payments-gw' (façade), 'wallet', 'psp-adapters-', 'fraud-check'.
Flux : 'init → reserve → capture/rollback' (saga).
События: `PaymentInitiated`, `PaymentAuthorized`, `PaymentSettled/Failed`.
Idempotence : 'Idempotency-Key', dedup dans 'wallet'.

12. 2 CUS/Conformité

Сервисы: `kyc-flow`, `doc-storage`, `sanctions-check`, `pep-screening`.
События: `KycSubmitted/Approved/Rejected`, `RiskScoreUpdated`.
Audit et ETA : file d'attente de tâches, case time-line, post-actions.

12. 3 Bonus/Missions

Services : 'bonus-engine', 'wallet-bonus', 'eligibility'.
Chorégraphie : « BetPlaced → BonusEngine → BonusGranted → WalletCredited ».
Protection contre les abus : subventions idempotent, limites, simulateur de règles.

12. 4 tournois/Liderboards

Services : 'tournament-svc', 'scoring', 'leader'.
Stockage : Redis ZSET + « rasage » périodique dans OLAP.
События: `ScoreUpdated`, `TournamentClosed`, `RewardIssued`.

13) Exemple « contrat + événement » (simplifié)

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 (fragment) - événement

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

14) Tests

Unit/Property-based pour les règles de domaine.
CDC (Pacte/Assertable) est un contrat-test de fournisseurs/consommateurs.
Intégration avec les courtiers locaux (Testcontainers).
E2E flow critique (registratsiya→depozit→start igry→vyvod).
Tests Chaos/Failover : Désactivation du PSP/chute du courtier/perte de zone.

15) Métriques et SLO (minimum)

Disponibilité des services : '≥99. 9 % pour le paiement/portefeuille.
Latitude p95 : API de chemin critique ≤ 300-500 ms.
Error budget: 0. 1–0. 5 % par trimestre, burn-alerts.
Files d'attente : lead time event (produce→consume), DLQ ≤ 0. 1%.
Affaires : TTP, TtW, FTD-success, KYC-TtV.

16) Chèques-feuilles

Conception du service

• Délimitation claire du domaine et propriétaire des données.
• Contrats OpenAPI/AsyncAPI + schémas dans Registry.
• Les SLO/alertes sont définis ; métriques/remorques/logs intégrés.
• Politiques de Timaout/Rétroactivité/Idempotence.
• Migrations de schémas : expand-and-contract.

Avant la sortie

• Les tests d'intégration Unit/CDC sont verts.
• Itinéraire canarien et plan de repli.
• Les routes de vitesse/de poids sont personnalisées.
• Les secrets/clés/certificats tournent.
• Les drapeaux et les follbacks sont préparés.

17) Anti-modèles

Le réseau est comme un bus de données : chaînes synchrones profondes au lieu d'événements.
Un « dieu » commun - BD sur tous les services.
L'absence d'idempotence → les doubles charges/charges.
Sorties sombres sans télémétrie et sans kill-switch.
Session cachée (collante partout au lieu de l'état extérieur).
Contrats « en code » sans version et CDC.
Logique dans une passerelle API au lieu de services (passerelle = mince).

18) Migration à partir d'un monolithe (Strangler Fig)

1. Allouer la façade-passerelle et la première boucle (par exemple, les paiements).
2. Retirer la logique binaire (outbox) du monolithe aux événements.
3. Transférer progressivement les endpoints vers un nouveau service (routage/poids canaris).
4. Comprimez le monolithe au « noyau » et éteignez-le.

19) Pile et infrastructure (exemple)

Communications : REST/gRPC, Kafka/NATS ; Schema Registry.
Stockages : PostgreSQL, Redis, OpenSearch, S3/MinIO ; OLAP — ClickHouse/BigQuery.
Conteneurs/orchestration : Docker, Kubernetes (Ingress/Gateway), Service Mesh (Istio/Linkerd) si nécessaire.
Passerelle : Envoy/Kong/Traefik/NGINX.
CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; Pact/OWASP/ZAP.
Observability: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) Triche finale

Concevez les limites par domaine et responsabilité des données.
Synchron - seulement là où une réponse est nécessaire maintenant ; le reste est des événements.
Contrats/régimes/CDC - Assurance régression.
Saga + outbox + idempotence - la base de la fiabilité.
L'observation et le SLO ne sont pas une option, mais un critère « prêt ».
Sorties par canary/blue-green, migrations - expand-and-contract.
Sécurité/conformité : mTLS, JWT, KMS, données régionales.
D'abord le monolithe modulaire, puis l'évolution - si l'échelle et l'équipe sont prêtes.