Bulkhead limita recursos; circuit breaker decide tentativas

No desenho do exercício, limite a oito chamadas locais ativas de frete por instância e a dez solicitações em espera. Rejeite nova admissão ao atingir a fila e retire quem ultrapassar 20 ms. O restante da aplicação usa capacidade separada. Esses limites representam uma proposta a testar, não dimensionamento baseado em carga real.

Com três instâncias, o teto local configurado soma até 24 chamadas ativas, não oito globais. Tampouco limita automaticamente o trabalho remoto que continuou após cancelamentos. A implementação deve liberar a vaga quando o recurso local realmente termina; liberar ao devolver timeout pode esconder trabalho ainda em execução.

Um circuit breaker acrescenta outra decisão: suspender tentativas após observar falhas e permitir sondagens controladas de recuperação. Ele não substitui fila limitada nem teto de concorrência. Antes de abrir, chamadas podem se acumular; depois de reabrir, um fluxo sem admissão pode saturar novamente a dependência.

Defina quais erros contam e como distinguir indisponibilidade de uma recusa comercial válida. Cotação inexistente para um destino não significa necessariamente fornecedor doente. Escolher estado por taxa de erro exige janela, amostra mínima e transições compreensíveis para operação.

Como política didática, considere os dez últimos resultados de transporte, exigindo dez observações: cinco falhas abrem o circuito por dez segundos. Depois, uma sondagem por instância permite testar recuperação; sucesso fecha o circuito e reinicia a janela, falha reabre por dez segundos. Use relógio monotônico para intervalos. Esses parâmetros não foram calibrados; uma sondagem bem-sucedida pode ser insuficiente para retomar toda a carga.

Chamadas já em andamento não desaparecem quando o circuito abre. Rejeições pela fila local também não são novas observações do fornecedor. Separar essas contagens evita interpretar saturação da própria aplicação como prova de falha remota.

Retry precisa caber no mesmo orçamento

Neste caso, a política inicial é não repetir automaticamente após o trecho da dependência esgotar os 300 ms, incluindo a admissão. Falhar de forma controlada pode ser melhor que acrescentar outra espera sem tempo útil. O cliente recebe um resultado que permite uma nova ação consciente, conforme a experiência definida pelo produto.

Se posteriormente houver repetição para falha transitória rápida, escolha uma camada responsável, limite tentativas e mantenha o prazo original. Espaçamento crescente e variação aleatória podem evitar repetição sincronizada, mas também consomem o orçamento. Não transformam uma dependência saturada em capacidade disponível.

Três camadas com até três tentativas cada podem produzir até 27 chamadas na camada mais profunda para uma operação, quando todas repetem dessa forma. É um limite aritmético desse desenho, não uma medição. Descrever tentativas incluindo a primeira evita confundir três tentativas com três retries adicionais.

Degradação precisa respeitar o negócio

Frete gratuito inventado não é um fallback válido para cotação indisponível. O exercício devolve uma condição explícita de ausência de cotação e impede confirmar a compra sem preço de entrega válido. A loja pode continuar permitindo navegação de produtos se seus próprios recursos permanecem protegidos.

Isso preserva uma regra, mas tem custo comercial: algumas compras ficam bloqueadas. Uma cotação em cache só seria alternativa após definir validade, destino, itens e quem assume eventual diferença. Disponibilidade aparente não compensa uma promessa financeira que a empresa não aprovou.

Registre a causa para operação sem despejar detalhes internos no usuário. Métricas precisam distinguir timeout, rejeição por capacidade, breaker aberto e resposta comercial sem tarifa. Agregar tudo como erro de frete dificulta saber qual intervenção está funcionando.

Recuperação também faz parte do desenho

Depois de um intervalo definido, permita poucas sondagens, ainda respeitando prazo e capacidade. Se falharem, suspenda novamente; se forem bem-sucedidas, retome tráfego conforme a política escolhida. Observe se fila e recursos retornam ao normal, em vez de apenas conferir que o primeiro pedido voltou a passar.

Uma frota inteira fazendo sondagens simultâneas pode recriar pressão. O comportamento de recuperação precisa considerar instâncias e sincronização. Também é necessário reconhecer uma proteção presa no estado aberto após o fornecedor se recuperar, diferenciando falha externa de configuração local.

Defina quem pode alterar limites, como reverter uma mudança e quais sinais justificam intervenção. Sem essa responsabilidade, um conjunto de proteções vira configuração esquecida que só alguém consegue ajustar durante um incidente.

Ensaio de falha com expectativas verificáveis

Num ambiente isolado, use uma dependência controlável que responda devagar, recuse conexão e depois se recupere. Registre condições de carga e os limites acima. Observe chamadas ativas, tamanho da fila, espera de admissão, latência total e comportamento dos endpoints que não consultam frete.

Verifique se rejeições ocorrem nos limites configurados, se nenhuma nova tentativa ignora o prazo e se tarefas abandonadas continuam ocupando recursos. Depois restaure a dependência e observe sondagens e retomada. Confirme também que o checkout nunca apresenta uma tarifa fabricada.

Este artigo não executou esse ensaio. Os números e a tabela ajudam a especificá-lo. Um resultado positivo serviria apenas às condições observadas; capacidade de produção e falhas combinadas exigiriam evidências adicionais.

Limites da recomendação e público indicado

O ponto forte é ligar um defeito de integração à experiência e aos recursos do sistema. Os casos tornam consequências visíveis, mas não constituem experimento controlado que prove uma receita universal. Similaridade com um incidente do livro é motivo para investigar, não para copiar seus parâmetros.

Proteções também têm custo: rejeitar cedo reduz trabalho aceito, isolamento reserva capacidade e breakers acrescentam estados e ajuste. A edição de 2018 oferece conceitos úteis, mas bibliotecas e plataformas concretas precisam ser avaliadas em suas versões. Recursos distribuídos e gargalos compartilhados podem escapar a um isolamento apenas local.

Recomendo para quem já conhece HTTP, pools, concorrência e logs e começa a assumir responsabilidade por operação. Um iniciante pode acompanhar com pequenos ensaios; se ainda está aprendendo requisições básicas, vale consolidar isso primeiro. Um processo local sem dependências remotas talvez precise apenas de limites simples, sem toda essa infraestrutura.

Leituras complementares e veredito

DDIA aprofunda garantias e mecanismos dos dados. The Phoenix Project ajuda a discutir trabalho operacional e prioridades. Accelerate amplia a conversa sobre entrega. Release It! aproxima essa discussão do desenho das integrações e da contenção de falhas.

Leia um caso, desenhe recursos e esperas de uma chamada real, depois escolha uma proteção. Defina degradação e recuperação antes do ensaio. Revise os resultados com quem atende incidentes e com quem responde pela regra comercial.

Recomendo o livro para aprender a perguntar o que continua ocupado quando algo dá errado. Você aproveitou a leitura quando consegue explicar o dano contido, o trabalho recusado e a retomada, com evidência proporcional à promessa feita ao usuário.