Caso de uso: limite a taxa de transferência com fontes de dados externas e ações personalizadas limit-throughput
Nesta página: saiba como limitar o processamento de jornadas com ações personalizadas e fontes de dados externas para que os sistemas externos não fiquem sobrecarregados além do número de solicitações por segundo com suporte.
Use esse caso de uso para acelerar o processamento do jornada quando os sistemas externos precisarem lidar com um número limitado de solicitações por segundo.
Descrição do caso de uso
O Adobe Journey Optimizer permite que os profissionais enviem chamadas de API para sistemas externos por meio do uso de Ações Personalizadas e Fontes de Dados.
Isso pode ser feito com:
-
Fontes de Dados: para coletar informações de sistemas externos e usá-las no contexto da jornada, por exemplo, para obter informações meteorológicas sobre a cidade do perfil e ter um fluxo de jornada dedicado com base nisso.
-
Ações personalizadas: para enviar informações a sistemas externos, por exemplo, para enviar emails por meio de uma solução externa usando os recursos de orquestração da Journey Optimizer junto com informações de perfil, dados de público-alvo e contexto de jornada.
Se você estiver trabalhando com fontes de dados externas ou ações personalizadas, convém proteger seus sistemas externos limitando a taxa de transferência do jornada: até 5.000 instâncias/segundo para jornadas unitárias e até 20.000 instâncias/segundo para acionadas pelo público-alvo. Saiba mais sobre taxas de processamento e taxa de transferência do jornada em esta seção.
Para ações personalizadas, os recursos de controle estão disponíveis no nível do produto. Consulte esta página.
Para fontes de dados externas, é possível definir limites de limite no nível do endpoint para evitar sobrecarregar esses sistemas externos por meio das APIs de limite do Journey Optimizer. No entanto, todas as solicitações restantes depois que o limite for atingido serão descartadas. Nesta seção, você encontrará soluções alternativas que podem ser usadas para otimizar sua taxa de transferência.
Para obter mais informações sobre como integrar com sistemas externos, consulte esta página.
Implementação
Para jornadas acionadas por público-alvo, você pode definir a taxa de leitura da sua atividade Ler público que afetará a taxa de transferência da jornada. Leia mais
Você pode modificar esse valor de 500 a 20.000 instâncias por segundo. Se você precisar ir abaixo de 500/s, também poderá adicionar condições de “divisão de porcentagem” com atividades de espera para dividir sua jornada em várias ramificações e executá-las em um momento específico.
Vamos ver um exemplo de jornadas acionadas por público que funcionam com uma população de 10.000 perfis e enviam dados para um sistema externo com suporte a 100 solicitações/segundo.
-
Você pode definir seu Público-alvo de leitura para ler perfis com uma taxa de transferência de 500 perfis/segundo, o que significa que levará 20 segundos para ler todos os perfis. No segundo 1, você lerá 500 deles, no segundo mais 2 500, etc.
-
Em seguida, você pode adicionar uma atividade de Condição “divisão de porcentagem” com uma divisão de 20% para ter a cada segundo 100 perfis em cada ramificação.
-
Depois disso, adicione as atividades Wait com um temporizador específico em cada ramificação. Aqui, configuramos uma espera de 30 segundos para cada um. A cada segundo, 100 perfis fluirão para cada ramificação.
-
Na ramificação 1, eles aguardarão 30 segundos, o que significa que:
- no segundo 1, 100 perfis aguardarão pelo segundo 31
- no segundo 2, 100 perfis aguardarão o segundo 32, etc.
-
Na ramificação 2, eles aguardarão 60 segundos, o que significa que:
- No segundo 1, 100 perfis aguardarão o segundo 61 (1’01’')
- No segundo 2, 100 perfis aguardarão o segundo 62 (1’02’') etc.
-
Sabendo que esperamos 20 segundos no máximo para ler todos os perfis, não haverá sobreposição entre cada ramificação, sendo os últimos 20 segundos em que os perfis fluirão para a condição. Entre o segundo 31 e o segundo 51, todos os perfis na ramificação 1 serão processados. Entre os segundos 61 (1’01’‘) e 81 (1’21’'), todos os perfis na ramificação 2 serão processados etc.
-
Como proteção, você também pode adicionar uma sexta ramificação para ter menos de 100 perfis por ramificação, especialmente se o sistema externo oferecer suporte apenas a 100 solicitações por segundo.
-
Como proteção adicional, você também pode usar os recursos de Limite.
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.