Conceitos
Hedged and tied requests
Intuição
É como pedir comida por dois aplicativos de delivery diferentes de uma vez quando você está com pressa: assim que um deles chegar, você cancela o outro pedido. Você paga um pouco mais caro (às vezes os dois cobram algo antes de cancelar), mas garante que não vai ficar esperando justamente o entregador que pegou trânsito. Isso não conserta o trânsito nem torna nenhum entregador mais rápido — só te protege de depender do azar de escolher o entregador errado.
Como funciona
O artigo de Dean e Barroso descreve duas técnicas que atacam a cauda de latência dentro de uma única requisição, em vez de tentar eliminar a variabilidade individual de cada servidor (considerada impraticável). Em 'hedged requests', o cliente envia a requisição a uma réplica primária e só dispara uma cópia para uma réplica secundária se a primeira ainda não respondeu depois de um tempo próximo ao p95 esperado; usa a resposta que chegar primeiro e cancela a outra — como a segunda cópia só sai quando a primeira já está demorando mais que o normal, a carga extra fica limitada a poucos por cento do tráfego total, mesmo reduzindo bastante a cauda. Em 'tied requests', a técnica é mais agressiva: o cliente enfileira a requisição simultaneamente em múltiplos servidores desde o início, mas avisa cada servidor sobre a existência da cópia nos demais, de modo que assim que um servidor começa a processar (ou termina), ele manda cancelar as cópias enfileiradas nos outros — evitando que trabalho duplicado se acumule desnecessariamente. Num sistema real do Google, tied requests reduziram a latência mediana em ~16% e o p99.9 em ~40%. A troca em ambas as técnicas é a mesma: mais carga (réplicas processando ou pelo menos enfileirando trabalho redundante) em troca de uma cauda de latência muito mais curta.
Na prática
Frameworks de RPC usados amplamente na indústria hoje oferecem políticas de hedging configuráveis como parte da própria biblioteca de comunicação entre serviços, sem que a aplicação precise reimplementar a lógica manualmente — uma escolha comum quando o custo de mais uma chamada redundante ocasional é bem menor que o custo de negócio de uma resposta lenta, mas que exige capacidade extra de servidor e cuidado para não amplificar carga em sistemas já perto do limite.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.