Pular para o conteúdo

apps/resiliency/bulkhead-pattern

107 · Resiliência & Tolerância a Falhas · ≈ 6 min de estudo

Bulkhead Pattern

Divide a capacidade de chamar um recurso compartilhado em pools separados por criticidade, de modo que o esgotamento de um pool não afete os demais. O nome vem dos compartimentos estanques do casco de um navio: um vazamento num compartimento não afunda o navio inteiro. Use quando cargas de importâncias diferentes disputam o mesmo serviço, conexão ou thread.

passos
6
arquivos
5
testes
0
tecnologias
4
Lógica puraTypeScriptBunElysiaStryker
Baixar cartão

Cenário

No fechamento do mês, 30 relatórios regulatórios de 1,5 s chegam ao core bancário junto com 20 PIX de 20 ms. Com um pool único de 10 conexões, os relatórios ocupam todos os slots e a fila, e todo PIX é rejeitado. Com um bulkhead por carga, os relatórios excedentes são descartados no próprio pool e os 20 PIX liquidam em dezenas de milissegundos.

Planta

Fluxo
6/6
RequisiçõesCargaBulkhead PIX8 slots + fila de 16Bulkhead relatórios2 slots + fila de 2Core bancárioHTTPErrorBulkheadFullrejeição imediataPIXrelatório regulatóriofila cheia
6

6 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Compartimentos evitam o naufrágio total.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    BulkheadSemaphore tem maxConcurrent slots e uma fila FIFO de no máximo maxQueueDepth chamadas

  2. 02

    Com slot livre, a operação roda; sem slot, espera na fila; com a fila cheia, lança ErrorBulkheadFull na hora (shed load)

  3. 03

    O slot é liberado no finally: operação que falha nunca retém capacidade, e o slot passa direto ao mais antigo da fila

  4. 04

    poolsIsolatedCreate dimensiona pela lei de Little — PIX 200/s × 20 ms ≈ 4 slots, dobrado para pico; relatórios, 2

  5. 05

    metrics() expõe inUse, utilization, queueDepth e shed por pool — o sinal para alerta e redimensionamento

  6. 06

    O demo roda a mesma rajada no pool compartilhado e nos pools isolados e compara o resultado dos PIX

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

  • Falha ou lentidão de uma carga não esgota a capacidade das outras

  • Rejeição imediata protege a latência de quem é aceito

  • Métricas por pool mostram qual carga está saturando

Custos

  • Capacidade ociosa num pool não é emprestada a outro

  • Dimensionar cada pool exige medir vazão e latência

  • Mais pools, mais parâmetros para ajustar

apps/resiliency/bulkhead-pattern

5 arquivos

src/

  • bulkhead.tsSemáforo com limite de concorrência, fila limitada, rejeição imediata e métricas
  • client_bank.tsCliente do core com um bulkhead por carga, ou um pool compartilhado para comparação
  • core_banking.tsCore bancário em ElysiaJS: PIX rápido, relatório lento
  • config_bulkhead.tsConfiguração validada do ambiente
  • demo.tsdemoRajada de fechamento do mês com pool compartilhado e com bulkheads

Executar · só Bun

  1. bun install# dependências
  2. bun run demo# roda o cenário
  3. bun run test# testes unitários
  4. bun run test:mutation# mutação com Stryker
Requisitos
Bun

Por que se relacionam

Teste rápido

Qual é o próximo passo depois de Bulkhead Pattern?

Próximo projeto · Resiliência & Tolerância a FalhasHealth Check
Esc

↑ ↓ navegarEnter abrir191 resultados