Cas d’utilisation : limiter le débit avec les sources de données externes et les actions personnalisées limit-throughput
Sur cette page : découvrez comment ralentir le traitement des parcours avec des actions personnalisées et des sources de données externes afin que les systèmes externes ne soient pas submergés par un nombre de requêtes par seconde supérieur à celui pris en charge.
Utilisez ce cas d’utilisation pour ralentir le traitement du parcours lorsque des systèmes externes doivent gérer un nombre limité de requêtes par seconde.
Description du cas d’utilisation
Adobe Journey Optimizer permet aux utilisateurs d’envoyer des appels d’API à des systèmes externes par le biais d’actions personnalisées et de sources de données.
Cela est possible grâce aux éléments suivants :
-
Sources de données : pour collecter des informations à partir de systèmes externes et les utiliser dans le contexte du parcours, par exemple pour obtenir des informations météorologiques sur la ville du profil et avoir un flux du parcours dédié basé sur ces informations.
-
Actions personnalisées : pour envoyer des informations à des systèmes externes, par exemple pour envoyer des e-mails par le biais d’une solution externe à l’aide des fonctionnalités d’orchestration de Journey Optimizer avec des informations de profil, des données d’audience et un contexte de parcours.
Si vous utilisez des sources de données externes ou des actions personnalisées, il peut être judicieux de protéger vos systèmes externes en limitant le débit des parcours : jusqu’à 5 000 instances/seconde pour les parcours unitaires et jusqu’à 20 000 instances/seconde pour les parcours déclenchés par une audience. Pour en savoir plus sur les débits et les taux de traitement des parcours, consultez cette section.
Pour les actions personnalisées, les fonctionnalités de ralentissement existent au niveau du produit. Voir cette page.
Pour les sources de données externes, vous pouvez définir des limites maximum au niveau du point d’entrée afin d’éviter de surcharger ces systèmes externes par le biais des API de plafonnement de Journey Optimizer. Toutefois, toutes les requêtes restantes une fois la limite atteinte seront ignorées. Dans cette section, vous trouverez des solutions de contournement que vous pouvez utiliser pour optimiser votre débit.
Pour plus d’informations sur l’intégration aux systèmes externes, référez-vous à cette page.
Mise en œuvre
Pour les parcours déclenchés par une audience, vous pouvez définir le taux de lecture de votre activité Lecture d’audience qui aura une incidence sur le débit des parcours. En savoir plus
Vous pouvez modifier cette valeur de 500 à 20 000 instances par seconde. Si vous devez descendre en dessous de 500/s, vous pouvez également ajouter des conditions de « partage en pourcentage » avec des activités d’attente pour fractionner votre parcours en plusieurs branches et les faire s’exécuter à un moment spécifique.
Prenons l’exemple d’un parcours déclenché par une audience s’exécutant avec une population de 10 000 profils et envoyant des données à un système externe prenant en charge 100 requêtes/seconde.
-
Vous pouvez définir votre Lecture d’audience pour lire les profils avec un débit de 500 profils/seconde, ce qui signifie que la lecture de tous vos profils prendra 20 secondes. Lors de la seconde 1, vous lirez 500 d’entre eux, lors de la seconde 2, 500 de plus, etc.
-
Vous pouvez ensuite ajouter une activité de condition de « partage en pourcentage » avec un partage de 20 % afin d’avoir à chaque seconde 100 profils dans chaque branche.
-
Ensuite, ajoutez les activités d’attente avec un retardateur spécifique dans chaque branche. Nous avons configuré ici une attente de 30 secondes pour chacune d’elles. À chaque seconde, un flux de 100 profils ira dans chaque branche.
-
Sur la branche 1, ils attendront 30 secondes, ce qui signifie que :
- lors de la seconde 1, 100 profils attendront la seconde 31
- lors de la seconde 2, 100 profils attendront la seconde 32, etc.
-
Sur la branche 2, ils attendront 60 secondes, ce qui signifie que :
- Lors de la seconde 1, 100 profils attendront la seconde 61 (1 min 01 s)
- Lors de la seconde 2, 100 profils attendront la seconde 62 (1 min 02 s), etc.
-
Sachant que nous prévoyons 20 secondes au maximum pour lire tous les profils, il n’y aura pas de chevauchement entre chaque branche, la seconde 20 étant la dernière durant laquelle les profils entreront dans la condition. Entre les secondes 31 et 51, tous les profils de la branche 1 seront traités. Entre la seconde 61 (1 min 01 s) et la seconde 81 (1 min 21 s), tous les profils de la branche 2 seront traités, etc.
-
Comme mécanisme de sécurisation, vous pouvez également ajouter une sixième branche pour avoir moins de 100 profils par branche, en particulier si votre système externe ne prend en charge que 100 requêtes/seconde.
-
Comme autre mécanisme de sécurisation, vous pouvez également utiliser les fonctionnalités de limitation.
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page explains how to limit journey throughput when external data sources or custom actions have a capped number of requests per second, using Read Audience rate configuration, percentage splits, and wait activities.
Intents:
- Limit the throughput of an audience-triggered journey to protect an external system from being overwhelmed
- Configure the reading rate of a Read Audience activity to control how many profiles enter per second
- Combine percentage split conditions and wait activities to spread profile processing over time
- Understand the difference between journey-level throughput workarounds and sandbox-level capping capabilities
- Apply capping capabilities to custom actions at the product level
Glossary:
- Throttling / throughput limiting: Controlling the rate at which profiles flow through a journey to avoid exceeding the request capacity of an external system. (product-specific)
- Read Audience reading rate: A configurable parameter on the Read Audience activity that sets the maximum number of profiles entering the journey per second (range: 500–20,000 instances/second). (product-specific)
- Capping API: A Journey Optimizer API that defines a maximum request limit per endpoint for external data sources; requests beyond the cap are dropped. (product-specific)
- Percentage split condition: A condition activity that divides the profile flow into branches by percentage, used here to distribute profiles across time-staggered wait paths. (product-specific)
Guardrails:
- Read Audience reading rate can be set between 500 and 20,000 instances per second; values below 500/s require a workaround using percentage splits and wait activities
- Unitary journeys support up to 5,000 instances/second; audience-triggered journeys support up to 20,000 instances/second
- The percentage-split + wait workaround operates only at journey level, not across all journeys in the sandbox
- When multiple journeys target the same external endpoint in parallel, this workaround does not account for the combined load — capping capabilities should be used instead
- Remaining requests that exceed the capping limit on external data sources are dropped, not queued
- The workaround must be thoroughly tested before going to production
Terminology:
- Canonical name: Throughput limiting — Acronym: none — variants: throttling, rate limiting, journey throughput control
- Synonyms: “Capping” = “throttling” in the context of external endpoint protection
- Do not confuse: “Capping API (endpoint-level)” ≠ “reading rate (journey-level)” — The Capping API applies globally to all journeys in a sandbox targeting an endpoint; the reading rate and split/wait workaround apply only to the individual journey
FAQ:
- Q: What is the maximum reading rate I can set on a Read Audience activity? — Between 500 and 20,000 profiles per second; to go below 500/s, use a percentage split with wait activities.
- Q: How do percentage splits and wait activities help limit throughput? — By splitting profiles into branches (e.g., 20% each) and adding staggered wait timers per branch, you ensure that only a controlled number of profiles reach the external system per second.
- Q: Does the percentage-split workaround protect all journeys targeting the same endpoint? — No; it only works at the individual journey level. If multiple journeys run in parallel against the same endpoint, use sandbox-level Capping capabilities instead.
- Q: What happens to requests that exceed the capping limit on an external data source? — They are dropped; the Capping API does not queue excess requests.
- Q: Should I use custom actions or data sources for external data use cases? — Custom actions are preferred because they support response handling; data sources should be used only when the use case specifically requires them.