Arquitetura de Plataforma de Gerenciamento de Agentes de IA: Lidando com Carga sem Mágica

Ao discutir Agentes de IA, o foco geralmente recai sobre a qualidade do modelo, prompts, raciocínio, alucinações, custo de tokens e velocidade de resposta. No entanto, removendo o ruído de marketing, um problema mais prático rapidamente emerge: como um sistema desses realmente funcionará sob carga?

Um usuário solicita a um agente que gere um relatório. Outro inicia uma verificação de dados no CRM. Um terceiro conecta um agente a um banco de dados, e-mail e API interna. Um quarto atribui ao agente uma tarefa que, por sua vez, gera dez ações internas adicionais. O que surge não é mais um simples "chatbot de IA", mas uma plataforma distribuída completa, exigindo controle sobre requisições, permissões de acesso, filas, limites, erros, novas tentativas, logs, segurança e o custo de execução. Este artigo detalha como uma plataforma de gerenciamento de Agentes de IA pode ser estruturada, não como um único chatbot monolítico, mas como uma camada distinta entre o usuário, o modelo, as APIs, os sistemas de negócios e a infraestrutura. A questão central é: como tal plataforma pode suportar a carga e evitar o caos à medida que o número de usuários, agentes e ações executadas aumenta?

Por que a Carga em uma Plataforma de IA é Diferente de um Serviço Web Comum

Em um serviço web clássico, um usuário faz uma requisição, o backend acessa um banco de dados, obtém um resultado e retorna uma resposta. Embora possam existir caches, filas, microsserviços, balanceadores e tarefas em segundo plano, a lógica geral é clara: requisição recebida, processada, resposta enviada. Com Agentes de IA, a situação é mais complexa. Uma única requisição do usuário pode se desdobrar em uma cadeia de ações:

O usuário pede: "Verifique os clientes com pagamentos em atraso, prepare um e-mail e sugira o próximo passo."

No nível da plataforma, isso não é mais uma única requisição. O agente precisa entender a tarefa, solicitar dados do CRM, verificar permissões de acesso, possivelmente consultar um banco de dados, classificar clientes, gerar texto, enviar uma ação para confirmação, registrar o resultado em um log, atualizar o status da tarefa e, talvez, agendar um acompanhamento no calendário. Ou seja, uma requisição externa se transforma em várias operações internas. Se houver centenas ou milhares de usuários, a carga aumenta de forma não linear. Surge um efeito de "multiplicação de ações": uma requisição do usuário pode gerar cinco, dez ou vinte eventos internos. É por isso que uma plataforma de IA não pode ser projetada como um simples "backend + API de LLM". É necessária uma arquitetura que antecipe a assincronicidade, o controle de ações, os limites, as filas e a tolerância a falhas.

A Ideia Principal: O Agente Não Deve Acessar Diretamente Onde Quiser

O primeiro princípio arquitetural de nossa plataforma é simples: um Agente de IA não deve ter acesso irrestrito e direto a APIs, bancos de dados e serviços internos. Se um agente puder decidir autonomamente para onde ir, quais dados solicitar e o que modificar, o problema, com o aumento da carga, torna-se não apenas técnico, mas também organizacional. O sistema começa a executar muitas ações, mas nem sempre é claro quem as iniciou, por que foram permitidas, qual limite foi aplicado e se é possível reproduzir o evento. Portanto, deve haver uma camada de execução separada entre o agente e os sistemas externos. Podemos chamá-la de camada de runtime ou camada de execução.

O agente não "acessa o CRM" diretamente. Ele formula uma intenção, como: "obter a lista de clientes com pagamento em atraso". Essa intenção passa por várias verificações:

• Quem solicitou a ação?
• Qual agente está executando a tarefa?
• Quais são suas permissões?
• Qual API ele deseja chamar?
• Quais dados serão afetados?
• O limite foi excedido?
• A confirmação humana é necessária?
• A ação pode ser executada agora ou precisa ser enfileirada?

Somente após essas verificações a plataforma permite ou nega a ação. Isso é crucial não apenas para a segurança, mas também para o gerenciamento da carga. Quando todas as ações passam por uma camada única e controlada, elas podem ser limitadas, enfileiradas, priorizadas, registradas e repetidas em caso de falhas.

Esquema Básico da Plataforma

Simplificadamente, a arquitetura pode ser representada da seguinte forma:

Usuário | API Gateway | Task Orchestrator | Policy Engine | Agent Runtime | Queue / Event Bus | Workers | APIs Externas / Bancos de Dados / CRM / E-mail / Serviços Internos

Cada camada resolve sua tarefa específica. O API Gateway recebe requisições externas, verifica autorização, limita a taxa de requisições e as roteia. O Task Orchestrator transforma a requisição do usuário em uma ou uma cadeia de tarefas, gerenciando o estado de execução (o que foi feito, o que aguarda confirmação, o que falhou, o que precisa ser repetido). O Policy Engine verifica as regras, atuando como o cérebro de segurança e controle, decidindo se um agente pode executar uma ação específica. O Agent Runtime gerencia a lógica do agente: interação com o modelo, ferramentas, contexto e passos intermediários. A Queue ou Event Bus lida com tarefas pesadas e em segundo plano para não manter o usuário esperando desnecessariamente. Os Workers executam as ações reais: acessam APIs, processam dados, geram relatórios, chamam serviços externos. Essa abordagem evita concentrar toda a carga em um único processo monolítico, permitindo escalar separadamente APIs, workers, a camada de interação com modelos, armazenamentos e componentes de auditoria.

Por que uma Fila é Obrigatória?

Em uma plataforma de IA, a fila não é uma "otimização adicional", mas um elemento praticamente obrigatório. A razão é simples: as tarefas dos agentes frequentemente têm duração imprevisível. Uma requisição pode ser concluída em dois segundos, outra em um minuto, e uma terceira pode exigir acesso a várias APIs externas que, por si só, podem estar lentas ou temporariamente indisponíveis. Executar tudo de forma síncrona rapidamente levaria o backend a timeouts, conexões saturadas e comportamento instável. O usuário clica, a requisição trava, o servidor mantém a conexão, os workers ficam ocupados, novas tarefas aguardam, e o sistema começa a degradar. A fila resolve esse problema. Uma API rápida aceita a tarefa, verifica condições básicas e a coloca na fila. O usuário recebe um status: "tarefa aceita". E então os "workers" retiram as tarefas conforme os recursos disponíveis. Isso oferece várias vantagens:

1. Controle de Carga: Se o número de usuários aumentar, a fila crescerá, mas o sistema não precisa cair imediatamente.
2. Priorização: Tarefas interativas do usuário podem ser executadas mais rapidamente, enquanto relatórios analíticos pesados são processados em segundo plano.
3. Retentativas: Se uma API externa estiver temporariamente indisponível, a tarefa pode ser repetida após 30 segundos, depois um minuto, depois cinco minutos.
4. Transparência: Cada tarefa tem um status claro: criada, enfileirada, em execução, aguardando confirmação, concluída, concluída com erro. Para uma plataforma de gerenciamento de Agentes de IA, isso é crítico. Um agente não deve simplesmente "ficar em silêncio" ou "travar". A plataforma deve saber exatamente onde a tarefa está e por que ainda não foi concluída.

Escalabilidade Horizontal: O Que Exatamente Escala

Quando se fala que "a plataforma suportará a carga", muitas vezes se refere a algo abstrato. Na prática, é preciso entender quais partes do sistema estão escalando. Em nossa arquitetura, escalamos separadamente:

• Servidores de API;
• Workers de execução de tarefas;
• Workers para acesso a LLMs;
• Workers de integração com APIs externas;
• Armazenamento de estado das tarefas;
• Serviço de logging e auditoria;
• Serviço de políticas e permissões de acesso;
• Cache;
• Fila de mensagens.

Por exemplo, se o número de usuários que apenas criam tarefas aumenta, podemos aumentar o número de instâncias de API. Se o número de operações pesadas em segundo plano cresce, escalamos os workers. Se o gargalo se torna a interação com modelos externos, podemos alocar um pool separado de LLM-workers com seus próprios limites. Se há muitas requisições semelhantes a regras de acesso, podemos adicionar cache para decisões de políticas onde for seguro. O principal erro é escalar tudo de forma monolítica. Se a plataforma é um grande monólito, ao aumentar a carga, é preciso levantar outro monólito idêntico, mesmo que o gargalo esteja em apenas um componente. Isso é caro, inconveniente e difícil de diagnosticar. É mais correto dividir o sistema de forma que cada camada possa ser escalada independentemente.

Rate Limiting: Proteção Contra Sobrecarga e Auto-destruição Acidental

Agentes de IA são perigosos não apenas por requisições maliciosas, mas também por erros comuns. Por exemplo, um usuário pode acidentalmente iniciar uma tarefa que gera muitas ações internas. Ou um agente pode interpretar mal um objetivo e começar a fazer requisições repetitivas. Ou uma integração com uma API externa pode começar a retornar erros, e o sistema pode tentar repetidamente sem critério. Por isso, são necessários limites. Os limites podem variar:

• Por usuário;
• Por organização;
• Por agente;
• Por tipo de ação;
• Por API externa;
• Por número de tarefas na fila;
• Por número de execuções paralelas;
• Por custo de requisições a LLMs;
• Por número de tokens;
• Por profundidade da cadeia de ações.

Por exemplo, um agente pode ter permissão para ler dados do CRM, mas não mais de 100 requisições por minuto. Ou um usuário pode iniciar no máximo três tarefas analíticas pesadas simultaneamente. Ou um agente não pode gerar uma cadeia com mais de 10 passos sem confirmação humana. Isso não é burocracia, mas um mecanismo de sobrevivência da plataforma. Sem limites, um sistema de IA pode criar sua própria carga, que depois não consegue processar.

Backpressure: Quando o Sistema Honestamente Diz "Mais Devagar"

Uma parte importante de uma arquitetura resiliente é o backpressure. É um mecanismo pelo qual o sistema não tenta aceitar um número infinito de tarefas se já é evidente que o processamento não está acompanhando. Em um cenário ruim típico, o backend aceita tudo, a fila cresce, o banco de dados começa a ficar lento, os workers se afogam, os usuários clicam repetidamente, a carga aumenta ainda mais e, no final, o sistema cai. Em um cenário bom, a plataforma entende antecipadamente que está sobrecarregada. Então, ela pode:

• Reduzir a velocidade de aceitação de novas tarefas;
• Diminuir a prioridade de operações em segundo plano;
• Desativar temporariamente ações pesadas;
• Retornar um status compreensível ao usuário;
• Colocar a tarefa na fila com uma previsão de espera;
• Pedir para repetir a requisição mais tarde;
• Mudar para um modo de processamento mais barato ou rápido.

Para uma plataforma de IA, isso é especialmente importante, pois parte da carga depende de serviços externos: API de LLM, CRM, sistemas de e-mail, bancos de dados do cliente, APIs corporativas internas. Mesmo que nossa infraestrutura funcione normalmente, um serviço externo pode começar a responder lentamente. A plataforma deve ser capaz de não cair junto com ele.

Cache: Onde Ajuda e Onde é Perigoso

O cache em uma plataforma de IA deve ser usado com cautela. Nem tudo pode ser cacheado. Podemos cachear:

• Catálogos;
• Dados públicos ou imutáveis;
• Configurações frequentemente usadas;
• Metadados de integrações;
• Algumas decisões de políticas;
• Resultados de cálculos caros;
• Templates de prompts;
• Estrutura de ferramentas disponíveis.

No entanto, é perigoso cachear dados que dependem de permissões de acesso, frescor da informação ou contexto pessoal. Por exemplo, se um agente solicita dados financeiros de um cliente, não se pode simplesmente pegar um resultado antigo do cache sem verificar a atualidade e as permissões. Portanto, o cache não deve ser "em todo lugar para acelerar", mas pontual. Em uma boa arquitetura, cada cache tem um tempo de vida, uma área de aplicação e a compreensão do que acontecerá com o envelhecimento dos dados. Para uma plataforma de gerenciamento de Agentes de IA, é especialmente importante cachear não os próprios dados de negócios perigosos, mas coisas técnicas: esquemas de ferramentas, ações permitidas, configurações de agentes, templates, resultados de verificações seguras. Isso reduz a carga, mas não cria riscos incontroláveis.

Separação de Tarefas Rápidas e Lentas

Nem todas as tarefas devem ser executadas da mesma forma. Por exemplo, um usuário pergunta: "Quais ações este agente pode executar?" Esta é uma requisição rápida que pode ser processada quase imediatamente. Mas se o usuário pede: "Analise 50 mil registros e prepare um relatório", esta é uma tarefa pesada. Ela não pode ser processada no mesmo fluxo onde as ações interativas rápidas são executadas. Portanto, na plataforma, as tarefas devem ser divididas em classes:

• Interativas rápidas;
• Em segundo plano comuns;
• Analíticas pesadas;
• Ações críticas que exigem confirmação;
• Tarefas periódicas;
• Tarefas de integração com APIs externas.

Cada classe deve ter seus próprios limites, filas, timeouts e regras de retentativa. Isso evita a situação em que um usuário inicia um relatório pesado e, para todos os outros, as requisições comuns param de abrir. Em uma arquitetura madura, tarefas pesadas não bloqueiam as rápidas. Este é um dos principais sinais de uma plataforma verdadeiramente pronta para a carga.

Estado da Tarefa: Por Que Não Armazenar Tudo Apenas na Memória

Um Agente de IA frequentemente executa uma tarefa em várias etapas. Ele pode iniciar o trabalho, solicitar dados, obter um resultado intermediário, pedir confirmação humana, continuar a execução, chamar uma API externa e concluir o processo. Se todo o estado for armazenado apenas na memória do processo, a tarefa será perdida ao reiniciar o servidor. Isso é inaceitável. Portanto, o estado das tarefas deve ser armazenado em um armazenamento externo, como um banco de dados. Lá são registrados:

• Quem criou a tarefa;
• Qual agente a está executando;
• Qual o status atual;
• Quais passos já foram concluídos;
• Quais ações foram permitidas ou negadas;
• Quais dados foram passados para as ferramentas;
• Quais erros ocorreram;
• Quais retentativas já foram feitas;
• Qual o resultado final obtido.

Isso é necessário não apenas para tolerância a falhas, mas também para auditoria. Em caso de disputa, a empresa deve entender por que o agente realizou uma ação, quem a iniciou, qual regra a permitiu e qual resultado foi obtido.

Idempotência: Proteção Contra Execução Repetida

Em sistemas distribuídos, a mesma tarefa pode, às vezes, ser executada repetidamente. Por exemplo, um worker enviou uma requisição para uma API externa, mas falhou ao registrar o resultado devido a uma falha. O sistema vê que a tarefa não foi concluída e a inicia novamente. Sem considerar a idempotência, pode-se obter duplicatas: dois e-mails para o cliente, dois débitos, duas atualizações de registro, duas chamadas criadas. Portanto, cada ação importante deve ter uma chave de idempotência – uma chave de operação única. Antes de executar uma ação, a plataforma verifica: essa operação já foi realizada antes? Para Agentes de IA, isso é especialmente importante. Um agente pode gerar ações semelhantes, e a plataforma deve distinguir uma nova ação de uma repetida. Este é mais um argumento para que o agente não controle diretamente os sistemas externos. Todas as ações devem passar por uma camada de execução controlada.

Human-in-the-Loop: Confirmação Humana Como Parte da Carga

Em sistemas corporativos de IA, algumas ações não podem ser executadas automaticamente. Por exemplo, enviar um e-mail ao cliente, alterar dados financeiros, excluir um registro, um envio em massa, alterar permissões de acesso – tudo isso pode exigir confirmação humana. À primeira vista, parece que a confirmação humana é apenas uma questão de segurança. Mas, na verdade, é também uma questão de carga. Se um agente chega a uma ação perigosa, a tarefa não deve ocupar um worker indefinidamente. Ela deve passar para o estado "aguardando confirmação". O worker é liberado, a tarefa é salva, e o usuário ou funcionário responsável recebe uma solicitação de confirmação. Após a confirmação, a tarefa retorna à fila e continua a execução. Essa abordagem permite não manter recursos ocupados enquanto o humano pensa. Em um sistema de larga escala, isso é crítico: a espera humana pode durar minutos, horas ou dias, e durante todo esse tempo, a tarefa não deve ficar na memória RAM.

Observabilidade: Sem Métricas, a Plataforma é Cega

Não se pode gerenciar a carga se ela não for visível. A plataforma deve coletar métricas em diferentes níveis:

• Número de requisições recebidas;
• Número de tarefas criadas;
• Tamanho das filas;
• Tempo de espera na fila;
• Tempo de execução das tarefas;
• Número de erros;
• Número de retentativas;
• Tempo de resposta das APIs externas;
• Número de ações de política negadas;
• Custo das chamadas a LLMs;
• Número de tokens;
• Carga nos workers;
• Carga no banco de dados;
• Porcentagem de tarefas concluídas com sucesso.

Logs e rastreamento são especialmente importantes. Quando um usuário diz "o agente fez algo errado", é preciso reconstruir a cadeia de eventos. Não apenas a resposta final do modelo, mas todo o caminho: qual foi a requisição, qual agente a processou, quais ferramentas foram chamadas, quais regras foram acionadas, o que foi permitido, o que foi bloqueado, onde ocorreu o erro. Sem isso, uma plataforma de IA se torna uma caixa preta. E uma caixa preta não pode ser escalada com segurança.

Políticas de Execução: A Carga Deve Ser Gerenciada por Regras

Um dos componentes-chave de nossa plataforma é a camada de regras. Ela é necessária não apenas para segurança, mas também para o gerenciamento de recursos. Por exemplo, uma regra pode ser:

• O agente pode ler dados de clientes apenas em horário comercial;
• Operações em massa são executadas apenas após confirmação;
• Tarefas de análise são executadas no máximo duas simultaneamente por organização;
• Em alta carga, tarefas pesadas são transferidas para baixa prioridade;
• Um agente não pode chamar a mesma API externa mais de N vezes em um curto período;
• Se o custo de execução exceder o limite, a tarefa é interrompida e requer confirmação.

Essas regras devem ser descritas não em código caótico dentro de cada agente, mas em uma camada de política separada. Assim, a empresa pode alterar as restrições sem reescrever toda a lógica dos agentes. É aqui que surge a ideia de uma linguagem especializada ou uma camada declarativa de gerenciamento de Agentes de IA. Não é necessário dar acesso ao código Python ou Go para o negócio. É possível descrever as regras de forma mais compreensível: quem, quando, o quê e sob quais condições pode fazer.

Como a Plataforma Lida com um Aumento Brusco de Carga

Imagine que pela manhã muitos usuários acessam o sistema simultaneamente. Alguns iniciam relatórios, outros pedem aos agentes para verificar negócios, outros conectam integrações, outros testam novos cenários. O que a plataforma deve fazer?

1. Aceitar requisições rápidas e não permitir que se misturem com tarefas pesadas.
2. Colocar operações longas em filas.
3. Aplicar limites por usuário, organização e tipo de tarefa.
4. Escalar workers, se a infraestrutura permitir.
5. Reduzir temporariamente a prioridade de tarefas que não exigem resposta imediata.
6. Não executar ações perigosas sem confirmação.
7. Mostrar ao usuário um status de execução compreensível, não apenas um indicador giratório.
8. Salvar o estado das tarefas de forma que, em caso de falha, a execução possa continuar.

É essa combinação que permite à plataforma lidar com a carga. Não um "super-servidor", não um modelo mágico, não um contexto infinito, mas uma arquitetura de engenharia normal.

O Que Será o Gargalo

Resposta honesta: gargalos sempre existirão :)

Em uma plataforma de IA, eles podem ser, por exemplo:

• Limites do modelo LLM externo;
• Velocidade de resposta das APIs externas;
• Banco de dados de estado das tarefas;
• Fila de mensagens;
• Serviço de políticas;
• Custo de tokens;
• Volume de logs;
• Agentes mal projetados;
• Cenários de usuário excessivamente pesados.

Portanto, a tarefa da arquitetura não é "nunca ter gargalos". Isso é impossível. A tarefa é tornar os gargalos visíveis, controláveis e isolados. Se uma API externa está lenta, toda a plataforma não deve cair. Se as tarefas analíticas estão sobrecarregadas, as requisições rápidas dos usuários devem continuar funcionando. Se um agente se comporta incorretamente, ele pode ser limitado ou parado sem desligar todos os outros.

Por Que um Chatbot Monolítico Não Suportará Tal Modelo...

É possível criar um chatbot simples que recebe texto, o envia para um LLM e retorna uma resposta. Para uma demonstração "de fachada", isso será suficiente. Mas assim que surgem ações reais, integrações e usuários, o esquema monolítico começa a falhar. Em um monólito, é difícil escalar tarefas pesadas separadamente. É difícil criar filas normais. É difícil controlar permissões no nível de cada ação. É difícil auditar. É difícil se recuperar de falhas. É difícil explicar por que um agente fez algo. É difícil limitar um cenário sem afetar os outros. Portanto, uma plataforma de gerenciamento de Agentes de IA deve ser não apenas um "chat com botões", mas uma camada de infraestrutura. Essencialmente, um runtime para a execução segura de ações de agentes.

Exemplo Prático de Execução de Tarefa

Suponha que um usuário escreva:

"Encontre clientes com pagamento em atraso, prepare um e-mail e mostre-me antes de enviar."

A plataforma executa isso não como uma única ação grande, mas como uma cadeia de passos, como:

1. O API Gateway recebe a requisição e verifica o usuário.
2. O Task Orchestrator cria a tarefa e salva seu estado.
3. O Policy Engine verifica se o usuário tem permissão para iniciar tal agente e trabalhar com dados financeiros.
4. O Agent Runtime forma um plano: obter lista de clientes, filtrar atrasos, preparar texto do e-mail, solicitar confirmação.
5. A ação de obter dados vai para a fila, um Worker acessa o CRM através de uma integração controlada.
6. O resultado é salvo no estado da tarefa, o agente gera o e-mail.
7. Antes do envio, a tarefa passa para o status "aguardando confirmação", o usuário clica em "confirmar".
8. Somente após isso, um worker separado envia o e-mail através da API de e-mail.

(Toda a cadeia é registrada no log: quem iniciou, quais dados foram usados, qual e-mail foi gerado, quem confirmou, quando foi enviado.)

Se em alguma etapa a API externa estiver indisponível, a tarefa não desaparece. Ela entra em retentativa ou em erro com um status compreensível. Essa é a diferença entre um agente de brinquedo e uma plataforma.

Como Reduzir o Custo da Carga

Em sistemas de IA, a carga não é medida apenas em CPU, RAM e RPS. Existe também o custo das chamadas a LLMs. Às vezes, este se torna o principal limitador. Para não esgotar o orçamento, a plataforma deve ser capaz de:

• Não enviar contexto extra para o modelo;
• Usar prompts curtos onde for possível;
• Cachear resultados intermediários seguros;
• Separar tarefas simples e complexas;
• Usar modelos mais baratos para operações simples;
• Interromper cadeias excessivamente caras;
• Calcular o custo de execução da tarefa antecipadamente ou, pelo menos, aproximadamente;
• Introduzir limites por usuário e organização.

Por exemplo, não é necessário enviar o histórico completo para o LLM a cada vez se a tarefa requer apenas a classificação de um evento. Não é necessário usar o modelo mais caro para extrair uma data simples de um texto. Não é necessário permitir que um agente "pense" infinitamente se ele já excedeu o limite de passos. O gerenciamento de custos é parte do gerenciamento de carga. Se a plataforma tecnicamente suporta as requisições, mas cada requisição é economicamente muito cara, tal arquitetura não pode ser considerada resiliente.

Segurança e Carga Estão Mais Conectadas do Que Parece

Frequentemente, a segurança é vista separadamente do desempenho. Mas em plataformas de IA, são coisas interligadas. Se não houver restrições de permissão, um agente pode solicitar muitos dados. Se não houver limites de ação, um agente pode sobrecarregar uma API externa e assim por diante nessa cadeia. Ou seja, a segurança não apenas ajuda a proteger contra ataques, mas também a manter o sistema em um estado gerenciável. Uma boa camada de permissões e políticas reduz a probabilidade de um agente criar acidentalmente uma avalanche de ações.

Tolerância a Falhas: O Que Acontece em Caso de Falha

Falhas são inevitáveis. Um worker pode cair. Um contêiner pode reiniciar. A conexão com uma API externa pode desaparecer temporariamente. O banco de dados pode ficar lento. O limite do modelo pode ser atingido. A plataforma deve estar preparada para isso. Para isso, as tarefas não devem ser perdidas ao cair um processo. A fila deve suportar retentativa de entrega. As ações devem ser idempotentes. O estado da tarefa deve ser armazenado separadamente. Os erros devem ser classificados: erro temporário, erro permanente, erro de permissão, erro de dados, erro de serviço externo. Se o erro for temporário, pode-se tentar novamente. Se o erro for permanente, a tarefa deve ser interrompida e a causa exibida. Se o erro estiver relacionado a permissões, não se deve tentar contornar a restrição. Se um serviço externo estiver indisponível, a plataforma não deve cair, mas sim transferir a tarefa corretamente para espera ou erro. Tolerância a falhas não é a ausência de erros. É a capacidade do sistema de sobreviver a erros sem perder o controle.

Como Saber Se a Plataforma Realmente Está Pronta Para a Carga

A prontidão para a carga não pode ser provada com palavras. Ela deve ser testada. Um conjunto mínimo de verificações:

1. Teste de carga da API;
2. Teste de crescimento da fila;
3. Verificação do comportamento em caso de queda de um worker;
4. Teste de retentativas;
5. Teste de idempotência;
6. Teste de limites;
7. Teste de API externa lenta;
8. Teste de falha do provedor de LLM;
9. Verificação de recuperação de tarefas não concluídas;
10. Verificação de logs e rastreamento;
11. Verificação de custo de cenários típicos.

Ufa, parece que nada foi esquecido... P.S. Bem, se algo foi esquecido, escreva nos comentários)

É importante testar não apenas o "caminho ideal", quando tudo funciona. É preciso quebrar o sistema deliberadamente e observar como ele se comporta. Se com a queda de um componente todo o resto...