Retry e backoff

São três mecanismos básicos de confiabilidade. Retry é tentar de novo após uma falha temporária, como uma API indisponível ou um limite de requisições atingido. Backoff exponencial é aumentar o intervalo entre as tentativas (1 s, 2 s, 4 s...) para não sobrecarregar o serviço que falhou. Timeout é o tempo máximo de espera por uma resposta antes de desistir. Os três precisam de limites. Tentativas infinitas sobre um modelo que responde mal só multiplicam o custo sem resolver o problema. São padrões antigos de sistemas distribuídos que se aplicam integralmente a chamadas de modelos de IA.

Em Produto, para chamadas de modelo, vale definir quantas tentativas, com que intervalo, e o que conta como falha. Um erro de API é falha e merece retry; uma resposta de baixa qualidade não é falha técnica e deve ir para o fallback, não para nova tentativa. Timeout é um requisito de produto, não apenas técnico: “resposta em até 5 segundos ou caminho degradado” é uma decisão de experiência. Por exemplo: 3 tentativas com backoff para erros de limite de taxa; depois disso, fallback para o modelo secundário; timeout de 8 segundos por chamada.

Use retry para falhas transitórias de infraestrutura, como indisponibilidade momentânea ou limite de requisições. Use fallback para falhas de qualidade, em que o modelo respondeu, mas mal. Use circuit breaker quando as falhas persistem e continuar tentando só piora. Uma forma simples de diferenciar: retry insiste um pouco; fallback muda de caminho; circuit breaker para de tentar por um tempo.

Padrões clássicos de sistemas distribuídos (backoff exponencial vem do protocolo Ethernet, 1973).

AWS Architecture Blog, Exponential Backoff and Jitter; Google SRE Book, Handling Overload