Bulkheads por dependência mantêm endpoints não relacionados disponíveis quando uma dependência fica lenta

Hipótese

O padrão bulkhead (citado) isola partes de uma aplicação em pools separados, de modo que, se uma parte falhar, as demais continuam funcionando; o Resilience4j (citado) o implementa como um semáforo que limita as execuções concorrentes ou como um pool de threads fixo com fila limitada. A hipótese é que o benefício do padrão é maior no caso da dependência lenta do que no da dependência fora do ar: uma dependência que responde pouco antes do timeout do cliente mantém um slot ocupado durante todo o timeout e, num pool compartilhado, isso deixa sem recursos até os endpoints que nunca a chamam. Com um pool limitado por dependência, as chamadas à dependência lenta são rejeitadas rapidamente assim que o pool dela enche, e os demais endpoints apresentam latência e taxa de erro próximas das de referência.

Previsão

Num serviço com os endpoints /a (chama a dependência A) e /b (chama a dependência B) que compartilham um único pool de tamanho P, injetar em A um atraso logo abaixo do timeout do cliente, sob uma taxa constante de requisições em modelo aberto, fará o p99 da latência e a taxa de erro de /b subirem ao nível de /a em poucos períodos de timeout. Com dois bulkheads de tamanho P/2, /b permanecerá dentro da sua referência, enquanto /a mostrará rejeições rápidas em vez de timeouts. Em condições normais, a vazão total de sucessos de /a será menor com o pool dividido, e esse é o custo do isolamento.

Teste proposto

1. Construir o serviço de dois endpoints com um pool compartilhado configurável ou com bulkheads de semáforo por dependência; manter os timeouts idênticos nas duas configurações.
2. Colocar um proxy de injeção de falhas à frente da dependência A e adicionar latência igual a cerca de 90 por cento do timeout do cliente.
3. Gerar carga nos dois endpoints com taxa de chegada fixa (modelo aberto) durante um período várias vezes maior que o timeout, uma vez por configuração.
4. Registrar, ao longo do tempo e por endpoint, a latência p50 e p99, o tipo de erro (timeout, rejeição) e a taxa de sucesso.
5. Repetir com A retornando erros imediatamente em vez de ficar lenta, para testar a afirmação de que, nesse caso, a diferença entre as configurações é menor.

Estado

Nenhum resultado é afirmado. O efeito depende de o pool ser de fato o recurso escasso; um serviço totalmente assíncrono pode mostrar a mesma falta de recursos por meio de limites de conexões ou de saturação do event loop, e o teste deve registrar qual recurso foi esgotado.