Automações
Retentativa com Backoff
Temporizador, contador de tentativas, teto e jitter compõem a retentativa com backoff. Após falha, o intervalo cresce, por exemplo, de 1 s para 2, 4, 8 e 16 s, reduzindo pressão sobre APIs, brokers e dispositivos. O custo é maior latência de recuperação. Uma ressalva decisiva: nem todo erro deve ser repetido. HTTP 429, 503 e timeout podem ser temporários; 400 ou credencial inválida exigem correção, não insistência.
⚙ Definição Técnica
Retentativa com backoff é uma política de recuperação em que uma operação que falhou é repetida após um atraso que aumenta ao longo das tentativas. Os componentes centrais são contador, função de atraso, teto máximo, número máximo, classificação do erro, jitter e condição de sucesso. Um perfil exponencial comum usa base de 1 s: 1, 2, 4, 8, 16 e 32 s, com limite de 60 s. Outros usam progressão linear, Fibonacci ou valor fornecido pelo servidor em Retry-After. O mecanismo reduz tempestades de requisições durante indisponibilidade e distribui clientes no tempo. O custo é aumentar a latência. A política deve ser aplicada apenas a falhas transitórias e a operações idempotentes ou protegidas por chave de idempotência. Repetir uma ação não idempotente pode duplicar cobrança, cadastro ou comando físico. Jitter aleatório evita que milhares de dispositivos reiniciados simultaneamente façam nova tentativa no mesmo instante.
Tipos comuns de gatilhos
Backoff exponencial para API indisponível
Uma chamada recebe timeout, HTTP 502, 503 ou 504. O cliente tenta após 1, 2, 4, 8 e 16 s, com teto. Cada tentativa possui timeout próprio. O tempo total precisa respeitar a validade do evento. Uma consulta de preço pode esperar; um evento de movimento não deve chegar minutos depois. Erros 400, 401 e 403 geralmente são permanentes até configuração mudar. Repeti-los consome recurso e pode bloquear conta. HTTP 429 deve respeitar Retry-After. Registre status, attempt e delay. Após o máximo, abra circuito, envie para fila de falha ou aplique fallback. Não ocultar: a automação precisa indicar que o serviço permaneceu indisponível.
Backoff com jitter para reconexão em massa
Após queda de energia, centenas de sensores, gateways e serviços podem reconectar juntos. Sem jitter, todos usam 1, 2, 4 s e sincronizam novas ondas. Full jitter escolhe aleatoriamente entre 0 e o atraso calculado. Equal jitter mantém parte fixa. Decorrelated jitter usa o atraso anterior. A escolha depende do sistema. Para residência pequena, poucos clientes já se beneficiam quando roteador e hub reiniciam. O objetivo é evitar pico no broker, DHCP, DNS ou nuvem. O atraso máximo precisa ser aceitável. Dispositivos críticos podem ter prioridade, mas não devem eliminar proteção.
Backoff para dispositivo offline
A automação envia comando e não recebe confirmação. Repetir pode ajudar em rádio instável. Entretanto, a integração pode já realizar retries na camada Zigbee, Z-Wave, Wi‑Fi ou Matter. Repetir acima aumenta tráfego. Conheça o protocolo. Use 2–3 tentativas espaçadas, valide estado atual e pare se o dispositivo voltar. Para ações de segurança, não presuma sucesso. Notifique. Em dispositivos a bateria, muitas tentativas podem gastar energia do coordenador e manter filas. Se o equipamento dorme, a mensagem pode ficar no parent. A política precisa considerar intervalo de polling, não apenas backoff genérico.
Backoff em processamento de fila
Um item falha e é reagendado com next_attempt_at. Isso libera o consumidor para outros itens, em vez de dormir dentro da execução. O registro guarda attempts, last_error e idempotency_key. Após N tentativas, vai para DLQ. Esse desenho escala melhor. A ordem pode mudar. Se é necessário preservar ordem por recurso, bloqueie apenas aquela chave. O item precisa de TTL. Um comando obsoleto deve expirar. Retentativas persistentes sobrevivem a reinício, mas podem reaparecer depois de o efeito ter ocorrido e o ACK se perdido. Idempotência é obrigatória.
Backoff adaptativo por resposta do serviço
O servidor fornece Retry-After, limite restante ou janela. O cliente usa esse dado em vez de fórmula fixa. Em MQTT, o broker pode fechar conexão por política; em APIs, cabeçalhos indicam rate limit. O algoritmo também pode aumentar atraso conforme latência e reduzir após estabilidade. A adaptação não deve oscilar. Limites mínimo e máximo. Erros permanentes interrompem. Para interoperabilidade, parseie formatos HTTP-date e segundos conforme RFC. Um erro comum é ignorar Retry-After e insistir, prolongando bloqueio. Respeitar o contrato melhora recuperação e reduz custo.
Considerações de Implementação
Retentar erro permanente apenas aumenta indisponibilidade e carga
Autenticação inválida, payload malformado, recurso inexistente e permissão negada não se resolvem com tempo. Classifique. 401 pode exigir renovar token; se a renovação falha, pare. 404 pode ser temporário apenas em consistência eventual, conforme contrato. 400 exige correção. Em dispositivos, configuração incompatível não melhora. A política deve mapear códigos e exceções. Um catch genérico que retenta tudo cria loops e oculta defeitos. Logs precisam mostrar classificação. Alertas devem diferenciar falha transitória esgotada de falha permanente imediata.
Operações não idempotentes podem ser duplicadas
A primeira tentativa pode ter sido executada e a resposta se perdido. Repetir “toggle”, “incrementar”, “criar” ou “abrir” pode produzir efeito adicional. Use comandos absolutos, idempotency key, operation_id ou consulta antes. Em HTTP, a segurança do método não basta: POST pode ser idempotente por contrato; PUT pode ter efeitos laterais. Em dispositivos físicos, feedback ajuda. Para uma fechadura, não repita destravar sem revalidar autorização e estado. A retentativa precisa preservar o contexto original e a validade temporal.
Teto, número e tempo total precisam ser calculados juntos
Atrasos 1+2+4+8+16+32 somam 63 s antes de incluir duração das chamadas. Se cada timeout é 10 s, o total pode exceder 2 min. Defina deadline global. O evento pode expirar antes. O teto evita horas. O número controla carga. O perfil deve refletir serviço. Para broker local, intervalos curtos. Para nuvem em incidente, mais longos. Teste. Métricas de tentativa por sucesso mostram se o backoff está mascarando degradação.
Circuit breaker complementa o backoff
Quando muitas operações falham para o mesmo serviço, cada uma com backoff ainda gera carga. O circuit breaker abre após limiar, falha rápido e testa recuperação depois. Isso protege threads e filas. O estado pode ser fechado, aberto e meio aberto. Em residência, uma entidade de saúde pode suspender automações dependentes da nuvem e usar fallback local. O circuito precisa de escopo por serviço. Uma falha de uma câmera não deve bloquear todas. Backoff trata tentativas individuais; breaker trata falha sistêmica.