À 9 h 02, un vendeur réimporte 600 000 offres après une correction de prix. La file catalogue monte, les stocks urgents attendent derrière les images et le checkout continue d’afficher des quantités anciennes. À 9 h 20, les retries de tous les connecteurs multiplient encore la charge.
Le problème n’est pas seulement le pic entrant. Chaque composant accepte le travail sans savoir si l’aval peut le terminer. Les files non bornées transforment la saturation en retard invisible, puis les producteurs interprètent les timeouts comme une invitation à renvoyer plus vite.
Le vrai enjeu du backpressure dans une marketplace opérateur est de préserver la fraîcheur des décisions critiques lorsque la demande dépasse la capacité. Contre-intuitivement, répondre immédiatement « accepté » peut être plus dangereux qu’un refus temporaire explicite.
Vous allez comprendre comment mesurer capacité, pression, quotas, files, priorités et reprise, puis rendre le ralentissement actionnable pour les sellers. Les commandes restent idempotentes, les queues sont bornées, et monitoring, retry_after, canary et rollback évitent qu’un flux massif dégrade toute la plateforme.
Définir la mission du ralentissement
Protéger une promesse métier
Le backpressure ne vise pas seulement un CPU sous 80 %. Il protège stock frais, commande acceptée à temps, prix cohérent et retour traité. La capacité est jugée par le délai maximal compatible avec ces décisions, pas uniquement par le débit technique.
Chaque pipeline déclare son backlog tolérable et l’âge maximal du plus vieux message. Une file de dix mille images peut rester saine ; cinquante mises à jour de stock âgées de quinze minutes peuvent déjà exposer une survente.
Faire remonter la pression au producteur
L’aval signale qu’il ne peut plus accepter au rythme courant. Le signal remonte jusqu’au vendeur ou service qui crée la charge. Accumuler dans un proxy intermédiaire masque la saturation et reporte l’incident au moment le plus difficile à récupérer.
Le producteur reçoit refus, délai conseillé ou quota restant avec un motif stable. Il peut ralentir, regrouper ou différer. Le protocole ne promet pas une ingestion illimitée suivie d’un traitement « dès que possible » sans échéance.
Mesurer la capacité utile
Relier débit et temps de service
La capacité dépend du coût par opération, des dépendances et du nombre de workers. Une offre simple, une image et une reconstruction de catégorie ne consomment pas la même unité. Le système mesure temps CPU, appels externes, écritures et taille.
Les budgets utilisent des unités pondérées plutôt qu’un nombre brut de requêtes. Une requête de 10 000 lignes peut coûter davantage que mille appels unitaires. Les poids sont calibrés depuis l’observation et revus quand le code change.
Conserver une marge de sécurité
La capacité nominale n’est pas le plafond exploitable. Incertitude, panne partielle et trafic acheteur nécessitent une réserve. Le budget vendeur utilise seulement la part disponible après flux internes critiques et marge de reprise.
Si les workers tiennent 2 000 unités par seconde mais que la latence explose au-delà de 1 600, alors le plafond reste sous ce coude. Un test de charge valide débit soutenu, pas un pic de trente secondes.
La mesure est rejouée avec une dépendance ralentie, un worker indisponible et des messages de tailles réelles. Le budget retient le plus faible débit compatible avec le SLA, puis réserve une capacité de reprise. Cette enveloppe est recalculée à chaque modification importante du code, du schéma ou du fournisseur aval.
Choisir les signaux de pression
Observer backlog, âge et saturation
Longueur de file, âge du message le plus ancien, temps de service, taux d’erreur et saturation des dépendances se complètent. Un seul indicateur peut mentir : une queue courte avec consumers arrêtés sur un flux rare reste critique.
Les signaux sont ventilés par type, priorité, seller et shard. Une moyenne globale ne révèle pas une partition bloquée. Les seuils ont une action : réduire quota, arrêter une classe, ouvrir un circuit ou déclencher le runbook.
Mesurer la fraîcheur business
Chaque offre conserve date source, ingestion, validation et publication. Le checkout sait l’âge du stock réellement rendu. Le monitoring relie pression technique à produits, commandes et vendeurs affectés, afin de prioriser une perte potentielle plutôt qu’un compteur abstrait.
Scénario : le backlog image atteint deux heures, mais le stock reste sous trente secondes. Le service continue les updates critiques et ralentit les médias. Si le stock dépasse son SLA, alors les offres concernées sont sécurisées ou masquées selon policy.
Allouer des quotas équitables
Séparer capacité garantie et burst
Chaque seller reçoit une part minimale liée au contrat et au besoin, puis peut utiliser une capacité burst lorsque le système est libre. Un gros vendeur n’accapare pas tous les workers ; un petit vendeur n’est pas bloqué par un batch sans rapport.
Les quotas portent unité pondérée, fenêtre, concurrence et taille de batch. Ils sont versionnés. Une exception commerciale possède plafond et expiration, car une promesse de débit modifie la capacité disponible pour les autres acteurs.
Éviter les identités contournables
Le quota s’applique au compte, à l’intégration et parfois au groupe seller, pas seulement à une clé API facilement multipliée. Les identités techniques sont reliées au contrat. Changer de token ne réinitialise pas le budget.
Si plusieurs connecteurs légitimes partagent un vendeur, l’allocation interne peut être déléguée avec sous-quotas. L’opérateur garde un plafond global et observe la distribution. Les abus déclenchent revue et accompagnement avant sanction automatique.
Borner les files
Refuser avant la saturation mémoire
Chaque queue possède capacité en volume et en âge. Lorsque la limite approche, l’ingestion ralentit ou refuse avant de consommer toutes les ressources. Une file disque infinie ne résout pas le coût de traitement ni la fraîcheur perdue.
Les messages expirables portent une deadline métier. Un prix promotionnel reçu après sa fin ne doit pas traverser tout le pipeline. Il rejoint un rejet explicable ou est remplacé par une version plus récente selon le contrat d’ordre.
Compacter les changements remplaçables
Plusieurs mises à jour absolues du même stock peuvent être compactées vers la dernière version ; des deltas ne le peuvent pas sans calcul. Le type de commande déclare sa sémantique. Une compaction aveugle perd des mouvements et casse l’audit.
La clé de compaction inclut seller, offre, entrepôt et version. Le manifeste compte reçus, remplacés, traités et rejetés. Le vendeur comprend pourquoi dix mises à jour n’ont produit qu’une publication finale.
Une réconciliation compare la dernière version acceptée, celle publiée et la source seller. Si une compaction supprime un état encore nécessaire, alors le lot est suspendu et la clé est corrigée. Les éléments touchés sont réextraits idempotemment ; la plateforme ne demande pas un réimport complet à tous les vendeurs.
Prioriser les flux métier
Distinguer urgent et volumineux
Stock, suspension de produit dangereux et acceptation de commande passent avant image, description ou réindexation complète. La priorité découle de l’impact et du délai, pas du seller le plus insistant. Elle est documentée et testée.
Des pools ou files séparés empêchent le trafic de fond d’épuiser les workers critiques. Une réservation de capacité protège les commandes même pendant un import massif. Les flux de faible priorité conservent un minimum pour éviter la famine.
Vieillir les travaux en attente
Un élément ancien peut monter progressivement en priorité si sa deadline reste pertinente. L’aging empêche un catalogue peu actif d’attendre indéfiniment derrière des stocks continus. Il ne fait pas passer un travail expiré devant un événement urgent.
Si une tâche dépasse son SLA, alors elle change d’état et ouvre une alerte avec population. Le système ne modifie pas seulement un score interne. Operations peut différer, accélérer ou annuler selon la valeur restante.
Contractualiser le ralentissement
Retourner une réponse actionnable
L’API utilise statuts, code stable, quota, unité, retry_after et identifiant de demande. Elle indique si rien n’a été accepté, si un batch est partiel ou si le traitement est différé. Le client ne devine pas depuis un timeout réseau.
Un retry_after reflète la pression sans garantir un instant exact. Le vendeur ajoute jitter et backoff exponentiel, conserve idempotency key et borne ses tentatives. Les SDK proposent ces comportements par défaut.
Fermer idempotence et reprise
Une commande rejouée avec la même clé retourne son résultat ou reprend l’exécution, sans dupliquer l’effet. La réponse distingue accepté, en cours, réussi, rejeté et expiré. Un batch possède un manifeste par ligne.
Les entrées du gateway sont identité, opération, coût, quota et pression ; ses sorties sont acceptation, délai ou refus motivé. Platform reste owner du protocole, chaque domaine de sa priorité et Seller Ops de la communication. L’instrumentation suit seuils, retries, files, dépendances, monitoring et rollback.
Accompagner les vendeurs
Exposer consommation et conseils
Le portail montre quota courant, consommation, backlog accepté, âge, rejets et prochaine récupération. Il recommande batch, fréquence et endpoints adaptés. Le seller peut corriger son connecteur avant de subir des erreurs aléatoires.
Le rapport hebdomadaire montre aussi heures de pointe, opérations coûteuses et économies obtenues par compaction. Seller Ops contacte les intégrations dont plus de 30 % des appels sont rejetés ou remplacés. Un plan daté propose batch adapté, webhook ou synchronisation différentielle avant toute réduction contractuelle durable.
Les messages distinguent limite contractuelle et ralentissement global. Une hausse temporaire de charge n’est pas présentée comme faute du vendeur. Les dates sont en UTC et les unités cohérentes avec les headers API.
Préparer les gros imports
Un canal bulk avec fichier, validation puis publication planifiée est préférable à des millions d’appels. Le seller connaît fenêtre, capacité et manifeste. Les imports sont découpés en cohortes et peuvent être suspendus.
Par exemple, une refonte de prix sur tout le catalogue est prévalidée puis exécutée hors pointe avec plafond. Les stocks continuent sur le flux prioritaire. Si les garde-fous tombent, le lot se met en pause sans perdre son checkpoint.
Prévoir pannes et dégradations
Propager une capacité réduite
Si le moteur de recherche, le PIM ou le PSP ralentit, les composants amont réduisent leur admission. Un circuit breaker seul protège les appels mais peut remplir les queues. La capacité disponible devient un signal partagé et borné.
Les modes dégradés déclarent ce qui continue : stock, commandes, lecture cache ou acceptation différée. L’interface ne promet pas une publication immédiate lorsque l’aval est coupé. Chaque mode possède critères d’entrée et de sortie.
Éviter la tempête de retries
Backoff, jitter, budgets de retries et dead letters empêchent tous les producteurs de repartir simultanément. Les retries consomment un quota distinct ou partagé selon risque. Une tentative ne doit pas affamer le trafic nouveau critique.
Si un incident dure plus que la rétention prévue, alors les travaux expirés sont annulés ou réextraits depuis la source. Le runbook n’essaie pas de rejouer aveuglément une file dont les prix et stocks sont devenus obsolètes.
Le mode dégradé conserve un registre des demandes acceptées, refusées et expirées par seller. À la reprise, ce manifeste permet d’annoncer précisément ce qui sera traité et ce qui doit être renvoyé. L’opérateur évite les consignes générales qui déclenchent une nouvelle vague de charge au même instant.
Organiser la reprise
Vider sans rechuter
Après incident, la capacité est partagée entre nouveau trafic et backlog. Ouvrir tous les workers sur l’ancien peut bloquer les mises à jour fraîches. Un drain rate progressif surveille aval et âge.
La reprise commence par les événements encore utiles et critiques. Les versions obsolètes sont compactées. Les sellers ne doivent pas renvoyer tout leur catalogue si les demandes acceptées restent garanties et consultables.
Réconcilier les effets
Les entrées du pipeline de reprise sont source d’autorité, manifests, checkpoints et événements publiés ; ses sorties sont manquants, doublons, expirés et corrections. Les owners valident leur domaine. Journalisation, seuils et runbook rendent chaque vague vérifiable.
Si plus de 0,1 % des offres d’une cohorte divergent après drain, alors la vague suivante s’arrête. L’équipe réextrait la population, corrige idempotemment et prouve la cohérence avant d’augmenter le débit.
Piloter capacité et dette
Mesurer service et équité
Le dashboard suit admission, débit, âge, rejects, retries, deadlines, fraîcheur et part de capacité par seller. Il distingue pression saine et travail perdu. Les percentiles révèlent les acteurs durablement pénalisés.
Le coût business inclut surventes, commandes retardées, visibilité obsolète, charge seller et support. La capacité est priorisée selon dommage évité. Chaque alerte possède owner, population et action.
Une revue mensuelle compare capacité promise, capacité consommée et dette de traitement. Si un seller occupe durablement plus de 40 % d’un pool partagé sans contrat correspondant, alors son flux est isolé ou replanifié. Si le trafic critique reste sous son SLA, aucune réduction arbitraire n’est appliquée aux autres acteurs.
Tester charge et rollback
Les tests reproduisent débit soutenu, seller dominant, dépendance lente, consumer arrêté et reprise. Le canary modifie quotas ou poids sur une cohorte. Le shadow compare décisions d’admission avant application.
Si l’âge du stock dépasse soixante secondes ou si la file critique approche 80 % de sa limite, alors le go est refusé. Le rollback restaure coefficients et quotas, puis vérifie que les messages acceptés gardent leur contrat.
Adapter la méthode et éviter les erreurs
Pour qui le backpressure convient
Il devient nécessaire dès qu’un producteur peut dépasser durablement un consommateur ou une dépendance. Une petite plateforme peut commencer par concurrence bornée, queue limitée et retry_after. Elle n’a pas besoin d’un ordonnanceur complexe pour refuser proprement.
Platform possède admission et capacité ; les domaines priorités et deadlines ; Seller Ops contrats et accompagnement ; SRE monitoring et incidents. Chaque quota commercial est validé contre la capacité mesurée.
Erreurs fréquentes du backpressure
Accepter tout, mesurer seulement CPU, utiliser une file infinie, traiter FIFO sans priorité, compter chaque requête pareil, renvoyer un timeout vague et relancer sans jitter sont les erreurs majeures.
Une autre erreur consiste à ralentir tous les sellers à cause d’un shard. Enfin, le rate limiting seul ne protège pas l’aval si les travaux acceptés restent trop coûteux. Capacité, coût et queue doivent partager le même modèle.
Plan d’action pour installer le backpressure
Semaines 1 à 4 : capacité et contrats
La première semaine mesure dix flux par coût et délai métier. La deuxième ferme unités, quotas, priorités, deadlines et limites de files. Platform, domaines et Seller Ops valident les scénarios de saturation. Une revue attribue chaque dépassement observé à un producteur, une dépendance et un owner, puis chiffre la capacité minimale réservée aux commandes et aux stocks avant tout changement.
Les semaines trois et quatre construisent admission, réponses API, idempotence et dashboards. Les tests couvrent batch massif, seller dominant, stock urgent, doublon, compaction, timeout et dépendance lente. Chaque demande obtient un état consultable.
Semaines 5 à 8 : charge et reprise
La cinquième semaine exécute une charge soutenue. La sixième ouvre un canary de quotas. L’instrumentation suit débit, âge, refus, retry, fraîcheur, équité et erreurs avec owners, seuils et runbooks.
Les semaines sept et huit coupent un consumer, provoquent une tempête de retries, testent le drain et exécutent le rollback. Le go exige stock sous SLA, queues bornées et sellers capables de reprendre sans réimport complet.
Le dossier final conserve capacités, poids, quotas, policies, fixtures, manifests, dashboards et procédures. Toute demande acceptée possède une promesse bornée. Tout refus donne une action. Toute priorité reflète un impact métier vérifiable.
- À faire d’abord : mesurer coût, fraîcheur et capacité soutenue.
- À tester ensuite : saturation, priorité, retry, drain et rollback.
- À différer : les optimisations sans backlog réel observé.
- À refuser : toute file illimitée ou réponse acceptée sans délai borné.
Ressources complémentaires pour l’opérateur
Structurer catalogue et exploitation
Le catalogue PIM marketplace fixe les grains des flux seller.
Les écrans du back-office opérateur rendent queues, quotas et incidents consultables.
Borner les premières charges
Le MVP marketplace avant ouverture aide à limiter les dépendances initiales.
La méthode pour ouvrir une première catégorie fournit une cohorte de charge contrôlée.
Conclusion : ralentir avant de casser
Le backpressure transforme une capacité limitée en décisions d’admission, de priorité et de reprise explicites.
Quotas équitables, files bornées et deadlines mesurées préservent la fraîcheur des flux qui portent un engagement immédiat.
Des réponses actionnables et une reprise réconciliée évitent que les sellers amplifient un incident par leurs retries, tout en conservant la preuve de ce qui a été accepté, différé ou refusé pendant chaque période de pression.
Dawap peut vous accompagner pour installer ce contrôle de charge dans votre marketplace opérateur.
