Modèles d'interaction des participants

(Section : Écosystème et réseau)

1) Contexte et objectifs

L'écosystème compte de nombreux acteurs (opérateurs, fournisseurs, services de paiement et KYC, affiliations, régulateurs, communautaires, développeurs). Les « modèles d'interaction » sont des moyens durables de partager la valeur et les données qui garantissent l'interopérabilité, la sécurité, la rentabilité et l'évolutivité.

• Réduisez les coûts de transaction et les délais d'intégration.
• Améliorer la fiabilité et l'observabilité des flux inter-nœuds.
• Équilibrer la vitesse (latitude) et la cohérence (cohérence).
• Mettre la conformité et les incitations économiques dans des protocoles d'interaction.

2) Taxonomie des participants et rôle

Opérateurs/tenants : service ultime pour les utilisateurs, propriétaire onbording et UX.
Fournisseurs/studios/noeuds de contenu : fournir des catalogues/API/events, SLA à émettre.
Services de paiement/risque : autorisation, compensation, chargbacks, scoring, limites.
Partenaires/affiliés : Ils amènent le trafic, génèrent des conversions Web, reçoivent des rapports.
Régulateurs/vérificateurs : exigent des journaux, des rapports, la localisation des données.
Communities/développeurs : Développent les SDK, créent des applications/bots/intégrations.

3) Canaux de communication et de transport

Requêtes synchrones : REST/gRPC pour RQ/RS, WebSockets/SSE pour les événements en direct.
Bus asynchrones : Kafka/AMQP/services de streaming, Pub/Sub pour les événements de domaine.
Webhooks : canal push-up vers un partenaire externe (obligatoire : signature, timeouts, retraits).
Interfaces de fichiers/batch : NACHA/CSV/Parquet pour les rapports et backfill.
Edge/PoP : mise en cache, WAF, taux-limites, validation de signature, réduction de latence.

4) Interactions de base (modèles de niveau protocole)

1. Request/Response (RQ/RS)

Utiliser pour les « solutions maintenant » : autorisation de paiement, vérification des limites, configurations.
Techniques : Timaoutes, circuit-breaker, retries avec gitter, clés idempotent.

2. Publish/Subscribe (Event-driven)

Pour la diffusion des faits : "le marché est terminé", "la balance a changé", "l'événement du jeu".
Techniques : parti clé (par user_id/tenant_id), dédup par message-key, stockage à long terme du journal.

3. Commande/Reply (Commandes asynchrones)

Commande « Faire » avec réponse/corrélation différée par correlation_id.
Techniques : modèle outbox, publication garantie, équipes de compensation.

4. Webhook Callback

Acceptez les notifications avec remise (at-least-once).
Techniques : signature de la requête, timestamp + anti-replay, idempotence sur le récepteur.

5. Batch/Delta Sync

Fermeture de nuit, rapports, synchronisation des manuels.
Techniques : snapshots + incréments, sommes de contrôle, schémas de versioning.

5) Coordination des processus : orchestration vs chorégraphie

Chorégraphie (événement) : les participants réagissent aux événements de domaine sans coordonnateur central.

Avantages : faible connectivité, évolutivité. Inconvénients : plus difficile à tracer/incidents.
Orchestration (saga) : le coordinateur gère les étapes et les rémunérations.

Avantages : contrôle transparent, prévisibilité. Inconvénients : point de concentration de la logique.

Saga (transactions de compensation) : séquence d'étapes avec des actions réversibles en cas d'échec. Pour les finances/bilans - un leader rigoureux et la minimisation des opérations de compensation est préférable.

6) Cohérence et données

Strong : paiements, limites, statuts KYC (leader unique, write-through, invariants synchrones).
Eventual/Timeline : télémétrie, catalogues, événements marketing (réplication asynchrone).
CRDT/versioning : pour les conflits rares dans les scénarios multi-master.
Outbox/CDC : afin que l'événement soit « toujours » publié avec l'enregistrement dans la base de données.
Identifiants : global, triable (ULID/KSUID), avec des préfixes régionaux pour le diagnostic.

7) Fiabilité et durabilité

Idempotence : clé au niveau de la requête/message, déduplication au récepteur.
Retrai : backoff exponentiel avec jitter ; limitation de la durée de vie de l'opération.
Délai et budget de retard : p95/p99 pour les itinéraires critiques.
Backpressure : limitation du parallélisme, file d'attente, priorité.
Modes Degrade : fonctionnalité partielle en cas de défaillance (cache, opérations différées).
Chaos/GameDays : exercices réguliers avec simulation des échecs d'intégration et de canaux.

8) Sécurité, confiance, conformité

Authentification/autorisation : OAuth2/OIDC, mTLS pour les S2S, tokens à courte durée de vie.
Signature des messages/webhooks : HMAC + timestamp + nonce.
Confidentialité/localisation : PII/PCI dans la « zone de confiance » de la région, minimisation du champ de données dans les événements (minimisation des données).
Audit et logs immuables : corrélation par trace_id, stockage des preuves de livraison/lecture.
Secrets et clés : KMS per-region, rotation, policy-as-code.
Antifrod et risque : scoring à l'entrée, limites par participant/canal, signaux comportementaux.

9) L'économie des interactions et des incitations

Contrats de monétisation : RevShare/royalties, tarifs API (tiered), pénalités/crédits-notes pour SLA.
Fair use : quotas, taux-limites, priorité par niveau d'affiliation.
Cost-aware routing : si plusieurs fournisseurs sont équivalents à SLA - choisir plus économique.
Reporting transparent : statuts de livraison, dashboards de consommation, limites de self-service.

10) Observabilité et SLO

Traces : trace_id/span_id de bout en bout dans RQ/RS et événements.
Métriques : latency p50/p95/p99, taux d'erreur, file d'attente, part de cache-hits, egress.
Logs : structurés, avec des tenant_id/partner_id/region/release.
Alerting : SLO par canal et intégration ; priorité par impact sur les entreprises (par exemple, paiements> télémétrie).

11) Modèles types de contrats

1. REST/gRPC contrat :

Versioning BouVer, champs obligatoires : idempotency-key, request-id, trace-context.
Réponses : codes d'erreur déterministes, retry-hints, link sur l'état de l'opération asynchrone.

2. Contrat d'événement :

Поля: event_id, occurred_at, producer, subject_id, version, schema_ref.
Garanties : au moins une fois, lot clé, TTL/retraite.

3. Contrat Webhook :

Titres : signature, timestamp, nonce, delivery-id.
Comportement : 2xx = confirmation ; Retrai de backoff à N heures, idempotence sur le récepteur.

12) Modèles d'onbording partenaires

Bac à sable et clés de test, répertoire public API/events, Postman/SDK, exemples.
Portail self-service : création de webhooks, configuration des filtres d'événements, affichage des logs de livraison.
Raids de garde intégrés : limites de défaut, avertissements avant l'auto-régulation.
Certification des intégrations : chèques-listes, auto-tests contractuels, statut « marketplace ».

13) Risques et anti-modèles

« Chaîne de dominos » synchrone : RPC longs sur les systèmes des autres → faïences en cascade.
Absence d'idempotence : prise de paiement/événement.
Circuits sans versioning : cassent les consommateurs lors des sorties.
Un « maître vérité » global pour tout le domaine : consistance interrégionale chère/fragile.
Économie opaque : les partenaires ne voient pas la consommation → les conflits et la méfiance.

14) Indicateurs de santé des interactions

Taux de réussite des livraisons d'événements (%) et tag moyen.
p95/p99 retards sur les itinéraires critiques (paiement, calcul des résultats).
Erreurs 4xx/5xx par intégration/canal, incidents MTTR.
Proportion de prises traitées idempotent, niveau de cache-hits.
Coût pour 1k demandes/events et egress par partenaire.
Conversion de l'onbording des partenaires : temps « key-to-first-success ».

15) Chèque de mise en œuvre

1. Classer les interactions : synchrone vs events, criticité de consistance.
2. Identifiez les SLO et les délais, incluez les circuits-breakers et les backoff.
3. Entrez l'idempotence partout (clés, dedup, replays).
4. Formalisez les versions schémas/contrats et la politique « expand → migrate → contract ».
5. Activez les signatures et l'anti-replay pour les webhooks, KMS per-region.
6. Construisez l'observation de bout en bout et les portails self-service.
7. Automatisez la certification des partenaires et les tests de régression des contrats.
8. Bâtissez l'économie : quotas, limites, reporting, rowting cost-aware.
9. Organisez régulièrement des GameDays pour les intégrations (dégradation des canaux, retraits massifs).
10. Revisitez la matrice des domaines une fois par trimestre : où renforcer strong, où affaiblir.

16) FAQ

Que choisir : orchestration ou chorégraphie ? Pour les processus complexes et critiques, l'orchestration ; pour une grande échelle - chorégraphie avec des contrats clairs.
Comment éviter les prises ? Clés idempotent + dedup sur le récepteur + logique « exactly-once-like » sur les consommateurs.
Comment accélérer l'engagement des partenaires ? Bac à sable, SDK/scripts d'exemple, vérifications automatiques des sites Web et pages d'état.
Comment intégrer la conformité ? Réduisez les champs PII dans les événements, stockez les opérations clés dans les « zones de confiance », effectuez un audit immuable.

Résumé : Les schémas d'interaction ne sont pas seulement des protocoles, mais aussi un ensemble d'incitations économiques, de raids de garde et d'observabilité. Formalisez les contrats, partagez les domaines par cohérence, faites de l'idempotence et des retraits « par défaut », donnez aux partenaires des outils et des métriques transparents - et l'écosystème croîtra de manière durable et prévisible.