Wzorzec bulkhead dzieli ograniczone zasoby między funkcje lub grupy klientów. Gdy jedna zależność odpowiada wolno, jej żądania zajmują własną pulę połączeń, pracowników albo kolejkę. Pozostałe pule mogą nadal obsługiwać ruch. Granicę wyznaczają wymagania biznesowe i scenariusze awarii, nie nazwa mikroserwisu.

Przykład fikcyjny: zamówienia i raporty wywołują różne usługi, lecz używają tej samej puli 40 połączeń. Spowolniony raport zajmuje pulę i blokuje zamówienia. Oddzielne limity współbieżności oraz ograniczona kolejka raportów pozwalają utrzymać krytyczną ścieżkę kosztem opóźnienia raportu.

Jak podjąć decyzję?

  1. Ustal, które funkcje muszą działać mimo awarii innej zależności.
  2. Zmierz obciążenie, czas odpowiedzi, nasycenie puli i długość kolejki dla każdej funkcji.
  3. Przypisz osobny limit, timeout i zachowanie po przeciążeniu. Testuj spowolnienie przy reprezentatywnym ruchu.

Kompromis: osobne pule mogą pozostawić niewykorzystane zasoby i zwiększają liczbę parametrów operacyjnych. Nie izoluj wszystkiego automatycznie; dobierz granicę do kosztu awarii.

Źródło: Microsoft Azure Architecture Center — Bulkhead pattern ↗