Atualização no Comportamento de Retry dos SDKs da AWS: O Que Você Precisa Saber

A AWS anunciou uma atualização significativa no comportamento de retry dos seus SDKs, visando melhorar a experiência do desenvolvedor e a eficiência das aplicações.

Recentemente, a Amazon Web Services (AWS) anunciou uma atualização no comportamento de retry dos seus SDKs, que promete melhorar a forma como as aplicações lidam com erros temporários. Quando uma aplicação tenta acessar um serviço da AWS e a solicitação falha devido a um erro recuperável, o SDK da AWS agora tentará automaticamente realizar a operação novamente. Essa atualização é crucial, pois o comportamento de retry influencia diretamente a experiência do usuário em termos de erros e latência.

Historicamente, os padrões de retry variavam entre os diferentes SDKs da AWS. Alguns SDKs esperavam muito tempo antes de tentar novamente em caso de erros transitórios, enquanto outros continuavam tentando mesmo durante falhas prolongadas. A nova abordagem busca resolver essas inconsistências, estabelecendo padrões uniformes que serão aplicados a todos os SDKs da AWS.

A importância dessa atualização reside no fato de que um comportamento de retry mais eficiente pode reduzir significativamente a latência das aplicações e melhorar a experiência do usuário. Com a nova configuração, os desenvolvedores podem esperar que suas aplicações se recuperem mais rapidamente de erros temporários, o que é especialmente relevante em ambientes de produção onde a disponibilidade é crítica.

As mudanças introduzidas afetam tanto os modos de retry padrão quanto os adaptativos, que são baseados no modo padrão. A partir de agora, o modo padrão será o comportamento padrão para SDKs que anteriormente utilizavam modos legados, que não possuíam uma quota de retry padronizada e apresentavam comportamentos inconsistentes.

O novo modo padrão inclui uma quota de retry, um backoff exponencial com jitter e um conjunto padrão de erros recuperáveis. Isso significa que, em caso de falhas persistentes, o SDK irá parar de tentar após esgotar a quota, permitindo que o serviço se recupere mais rapidamente. Essa abordagem não apenas melhora a eficiência, mas também reduz a latência do lado do cliente, evitando que as aplicações fiquem esperando por tentativas de retry que provavelmente não terão sucesso.

Para desenvolvedores que estavam utilizando o modo legado, essa atualização representa uma mudança significativa. O modo legado não tinha uma quota de retry padronizada, o que resultava em tentativas contínuas, independentemente do número de falhas.

Com a nova configuração, cada tentativa de retry em caso de erro transitório agora consome 14 tokens, enquanto as tentativas após respostas de throttling consomem 5 tokens. Essa mudança permite que a quota se esgote mais rapidamente durante falhas sustentadas, ajudando a resolver problemas de disponibilidade de forma mais eficiente.

Além disso, a primeira tentativa após um erro transitório agora ocorre de forma mais rápida, com um tempo médio de espera de cerca de 25 ms para uma resposta HTTP 503, em comparação com centenas de milissegundos anteriormente. Essa redução no tempo de espera é um avanço significativo para aplicações que dependem de respostas rápidas.

Os desenvolvedores também devem estar cientes de que as operações de polling de longa duração, como a operação ReceiveMessage do Amazon SQS, agora aplicam um atraso de backoff antes de retornar um erro quando a quota de retry se esgota. Essa mudança evita que um retorno imediato de erro cause loops de polling apertados, que podem aumentar o uso da CPU no cliente e gerar carga adicional no serviço.

Para aqueles que ainda não configuraram explicitamente o comportamento de retry, a nova configuração será aplicada automaticamente após a adesão ao novo padrão, que se tornará o comportamento padrão em novembro de 2026. Os desenvolvedores que optarem por testar a nova configuração devem fazê-lo em cargas de trabalho não produtivas inicialmente, para garantir que a nova abordagem funcione conforme esperado.

Embora a maioria das cargas de trabalho se beneficie dessa atualização, é importante que os desenvolvedores estejam cientes de que o número máximo de tentativas pode ter diminuído. Alguns SDKs que anteriormente permitiam mais de três tentativas máximas podem agora resultar em mais erros sendo reportados para a aplicação. No entanto, é possível restaurar o valor anterior de tentativas máximas, se necessário.

A nova configuração de retry traz uma quota de retry para SDKs que anteriormente não a tinham, permitindo que o SDK pare de tentar após atingir a quota durante falhas sustentadas. Isso não apenas melhora a experiência do usuário, mas também libera threads e conexões, evitando esperas desnecessárias.

Os desenvolvedores devem estar atentos às mudanças específicas de cada SDK e considerar a implementação da nova configuração em suas aplicações. A AWS recomenda que os desenvolvedores comentem sobre qualquer comportamento inesperado ou feedback positivo nas questões de rastreamento do GitHub de seus SDKs, pois isso pode ajudar a melhorar a implementação padrão para todos os usuários.

Em resumo, a atualização no comportamento de retry dos SDKs da AWS representa um avanço significativo na forma como as aplicações lidam com erros temporários. Com padrões mais consistentes e eficientes, os desenvolvedores podem esperar uma experiência de usuário melhorada e uma maior eficiência operacional em suas aplicações. Essa mudança não apenas reflete a evolução contínua da AWS em resposta às necessidades dos desenvolvedores, mas também destaca a importância de uma gestão eficaz de erros em ambientes de produção.

Para os executivos e tomadores de decisão, essa atualização deve ser vista como uma oportunidade para revisar e otimizar as configurações de retry em suas aplicações, garantindo que estejam alinhadas com as melhores práticas recomendadas pela AWS. A implementação dessas mudanças pode resultar em melhorias significativas na performance e na confiabilidade das aplicações, contribuindo para uma experiência do usuário mais fluida e eficiente.