ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Back-pressure

Quand l'aval ne suit pas, ralentir l'amont — plutôt que de laisser la queue grossir jusqu'à saturer la mémoire ou perdre des messages.

Problème

Un parser EDI ingère 5 000 INVOIC/seconde ; le validateur sémantique aval n'en traite que 2 000. Sans mécanisme de régulation, la queue entre les deux gonfle indéfiniment. Trois scénarios possibles, tous mauvais : (a) OOM kill du broker, (b) latence qui dérive à plusieurs heures, (c) drop silencieux quand le buffer est plein.

Forces

  • Les capacités sont inégales. Validateur, enrichisseur, writer ERP n'ont pas le même throughput.
  • Les pics arrivent. Un partenaire qui re-pousse 24h de DESADV après un incident sur sa pile envoie 100× le débit normal.
  • Drop silencieux est interdit en EDI réglementaire.
  • Le ralentissement doit remonter en cascade. Si le validateur ralentit, le parser doit ralentir, et l'entrée réseau doit refuser des nouvelles connexions.

Solution

Mettre en place un signal de saturation propagé du consommateur vers le producteur : à chaque étape, le receveur déclare sa capacité (taille de fenêtre TCP, demande Reactive Streams, drain timer Kafka), et l'émetteur s'auto-régule. Quand la pression s'élève, l'émetteur pause son producteur amont, qui pause le sien, jusqu'à atteindre l'entrée réseau qui refuse de nouvelles connexions (HTTP 429 / 503 avec Retry-After). 

producer ──messages──► [queue] ──messages──► consumer
                          │
                          ▼  capacity 10 000
   producer ─◄─ "slow down" / 429 / TCP RWIN=0 ─◄─ broker detects 95% full
   producer pauses or rejects new work

Implémentation EDI

En EDI, la back-pressure se matérialise à plusieurs niveaux : (1) AS2/AS4 répond 503 Service Unavailable avec Retry-After: 300 quand le hub est saturé ; (2) Kafka consumer groups détectent un lag > 30s sur un topic et coupent le producer en amont via une boucle de contrôle ; (3) RabbitMQ active le flow control natif au-delà de 95% de mémoire occupée ; (4) Reactive Streams (RxJava, Project Reactor, Akka Streams) implémentent le pattern dans le code applicatif avec un request(n) qui demande explicitement N éléments à l'upstream.

Anti-patterns

  • Queue infinie. Pas de back-pressure : le broker absorbe jusqu'au OOM kill.
  • Drop silencieux quand plein. Perte non observée, très coûteuse en EDI.
  • Sleep côté producer. Bloquer le thread plutôt que de signaler explicitement la pression côté consumer. Marche brièvement, ne se monitore pas.
  • Pas de propagation cross-stage. Le stage 4 ralentit mais le stage 1 continue de pomper : la queue intermédiaire explose.

Patterns liés

  • Rate Limiter — la régulation à débit fixe côté émetteur, complémentaire.
  • Bulkhead — l'isolation des pools pour empêcher la propagation des saturations.
  • Circuit Breaker — la coupure brusque quand l'aval échoue plutôt que ralentit.

Sources