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

Rate Limiter

Borner le débit accepté pour protéger l'aval — la complémentarité contractuelle de la back-pressure réactive.

Problème

Un partenaire EDI mal configuré pousse 50 000 INVOIC en deux minutes parce que son producteur a un bug. Si le hub accepte, l'aval (ERP, archivage, audit) est noyé pendant des heures. Si le hub refuse silencieusement, on perd des factures. La bonne réponse est entre les deux : refuser au-delà d'un débit contractuel, prévenir explicitement le partenaire et l'amener à respecter le débit.

Forces

  • Les SLA partenaires sont contractuels. Un partenaire a souscrit pour 1 000 INVOIC/jour. 50 000 en deux minutes est une violation.
  • L'aval a une capacité finie. Pas de magie : au-delà, la latence explose.
  • Les pics légitimes existent. Fin de mois, fin de trimestre — il faut absorber sans tout casser.
  • Le refus doit être explicite. HTTP 429, Retry-After, contact opérationnel — pas un silence.

Solution

Implémenter un compteur par clé d'identification (partenaire, IP, API token), incrémenté à chaque message reçu et décrementé selon un algorithme (typiquement token bucket ou leaky bucket). Au-delà du seuil, refuser avec un code explicite — HTTP 429 Too Many Requests + Retry-After, 503 Service Unavailable, ou code applicatif d'erreur côté AS2/AS4. Le partenaire est ainsi notifié, peut retenter, et son partenaire account manager peut être prévenu d'une volumétrie anormale.

Implémentation EDI

Cas concret : l'API gateway (Kong, AWS API Gateway, Cloudflare) applique un quota par partnerId. Le connecteur AS2 retourne un MDN négatif au-delà du débit contractuel. Kafka native quotas (producer-byte-rate, consumer-byte-rate) limitent par client ID. Sur l'API REST exposée aux partenaires, on documente la limite (1 000 msg/jour) dans le contrat technique et on l'enforce à l'ingress. Walmart, Stellantis et OpenPEPPOL imposent tous des contrats de débit dans leurs partner agreements.

Algorithmes

  • Token bucket : un seau de N jetons, rechargé à R jetons/seconde. Chaque requête consomme 1 jeton. Au-delà, refus. Algorithme dominant — autorise les bursts contrôlés.
  • Leaky bucket : les requêtes entrent dans une file, sortent à débit constant. Bursts absorbés mais lissés. Plus strict, idéal pour pacer un aval rigide.
  • Fixed window : compteur N par fenêtre (par minute, par heure). Simple mais sujet aux burst en bordure de fenêtre.
  • Sliding window log : journal des timestamps, compte sur la fenêtre glissante. Précis mais coûteux.

Anti-patterns

  • Pas de rate limit. Un partenaire mal configuré casse la production de tous les autres.
  • Limite globale unique. Pas de quota par partenaire = un partenaire bavard consomme tout le quota commun.
  • Refus silencieux. Drop sans réponse 429 — l'émetteur ne comprend pas ce qui se passe.
  • Limite trop basse pour les pics légitimes. Le partenaire est bloqué en fin de mois sur des volumes business normaux. Documenter le quota négocié.
  • Limite trop haute. Inopérante : ne protège pas l'aval réel. Mesurer la capacité réelle et caler dessus.

Patterns liés

  • Back-pressure — la régulation réactive aval→amont, complémentaire.
  • Bulkhead — l'isolation des compartiments, souvent avec un rate limit par compartiment.
  • Circuit Breaker — la coupure brusque quand l'aval échoue, à associer au rate limiter.

Sources