Jedna pula dla wszystkich zależności

Przykład fikcyjny. Nie opisuje konkretnej organizacji ani incydentu.

Sytuacja

Aplikacja obsługuje zamówienia i generuje raporty. Wywołania do obu zewnętrznych usług przechodzą przez tę samą pulę połączeń i kolejkę. Gdy raportowanie zwalnia, jego żądania zajmują pracowników. Zamówienia zaczynają czekać, chociaż ich własna zależność działa poprawnie.

Gdzie powstaje antywzorzec

Konfiguracja zakłada, że współdzielenie zasobów jest bezkosztowe. Niska ważność raportów nie ma odzwierciedlenia w limitach technicznych. Każde spowolnienie jednej zależności zużywa budżet czasu i współbieżności pozostałych. Podwojenie wspólnej puli może na chwilę zmniejszyć kolejkę, ale przy kolejnym skoku ruchu problem wraca.

Sygnały ostrzegawcze

• Krytyczne i pomocnicze wywołania korzystają z tej samej nieograniczonej kolejki.
• Jeden timeout obejmuje operacje o różnych celach jakościowych.
• Metryki pokazują tylko łączną liczbę połączeń, bez rozróżnienia zależności.
• Przy awarii dostawcy zwiększa się limit i liczbę ponowień, bez testu wpływu na inne funkcje.

Lepsza decyzja

1. Nazwij funkcje, które muszą działać podczas awarii innych zależności, i przypisz im budżety czasu.
2. Wprowadź osobne limity współbieżności, pule lub kolejki tam, gdzie izolacja odpowiada tej granicy. Dobierz pojemność do pomiarów, nie do arbitralnej liczby.
3. Ustal zachowanie po wyczerpaniu limitu: odrzuć nowe żądanie, odłóż pracę lub pokaż częściowy wynik. Zachowaj czytelny sygnał dla użytkownika.
4. Monitoruj nasycenie każdego segmentu i ćwicz spowolnienie jednej zależności pod obciążeniem.

Izolacja ma koszt: wolne zasoby jednej puli nie muszą być dostępne dla drugiej. Ten koszt porównaj z ceną wspólnej awarii. Nie każdy mały system wymaga wielu pul; decyzję uzasadniają priorytety i pomiary.

Reguła do zapamiętania

Gdy różne funkcje muszą przetrwać różne awarie, wspólna pula zasobów wymaga świadomego uzasadnienia.