Tempestades de retentativas historicamente impactam as operações comerciais e a confiança na marca. Embora o ajuste da configuração de retentativas e os orçamentos de retentativas forneçam mitigação significativa no nível de serviço, eles são configurados manualmente e carecem de visibilidade sobre a amplificação entre serviços causada por cadeias de dependência profundas e padrões de fan-out. Como resultado, pode ser difícil proteger a infraestrutura contra o efeito dominó desencadeado por uma única falha de serviço mais profunda na pilha.

Uma razão principal é que o comportamento de retentativa atual não é sensível ao contexto. Embora possamos controlar quantas retentativas ocorrem, não podemos controlar precisamente quando elas ocorrem. Isso decorre do desafio de distinguir de forma confiável entre erros gerados por um serviço e aqueles meramente propagados através dele. Como resultado, as retentativas são aplicadas uniformemente em vez de condicionalmente. Essa abordagem funciona para falhas transitórias ou de baixa taxa. No entanto, durante degradação moderada ou severa, torna-se contraproducente.

Retentar agressivamente contra um serviço já em dificuldades aumenta a carga, acelera a falha e amplifica o tráfego de retentativa nas dependências upstream. O que começa como uma interrupção localizada pode rapidamente escalar para um incidente em toda a pilha—em última análise, degradando, ou no pior caso, quebrando completamente a experiência do usuário final.

Pode-se argumentar que os códigos de erro dos serviços downstream poderiam ser traduzidos upstream para fornecer contexto para retentativas. Embora teoricamente possível, essa abordagem não escala no Uber devido ao grande fan-in e fan-out, fluxos de chamadas em evolução e à necessidade de mudanças adaptativas frequentes. Portanto, desenvolvemos um mecanismo sensível ao contexto em infraestrutura compartilhada para lidar com erros de forma mais eficiente. Este blog explica o mecanismo.