Przepływ działający przy dziesięciu zdarzeniach dziennie potrafi się zatkać przy tysiącu. Limity są zwykle po obu stronach.
Limity platformy
Liczba operacji, czas wykonania pojedynczego przepływu, wielkość przetwarzanych danych. Wszystkie trzy warto znać przed budową, bo każdy z nich narzuca inny sposób projektowania. Limit operacji wpływa na koszt, limit czasu na podział zadania, limit wielkości danych na to, czy plik da się w ogóle przepuścić przez przepływ, czy trzeba go przenieść inną drogą.
Osobno działają ograniczenia równoległości: liczba przepływów wykonywanych jednocześnie na koncie. Po jej przekroczeniu wykonania czekają w kolejce, więc przepływ szybki na próbach potrafi opóźniać się w godzinach szczytu.
Limity systemów docelowych
Interfejsy ograniczają liczbę zapytań. Przepływ przetwarzający dużą partię rekordów pojedynczo przekroczy je szybko. Odpowiedź o przeciążeniu trzeba obsłużyć osobno, ponowieniem z rosnącą przerwą, a nie traktować jak błąd trwały. Programy instalowane lokalnie mają inny rodzaj ograniczeń: obciążają bazę, z której korzystają jednocześnie pracownicy, więc masowy zapis w godzinach pracy spowalnia cały system.
Przetwarzanie partiami
Grupowanie rekordów zamiast obsługi po jednym. Rozwiązuje jednocześnie problem limitów i kosztu, bo liczba wywołań przestaje rosnąć razem z liczbą pozycji. Ma jeden minus: błąd w jednej pozycji potrafi przerwać całą partię, więc trzeba z góry ustalić, czy partia idzie w całości, czy pozycje wadliwe są odkładane osobno. Zależność kosztową opisuje tekst o rozliczeniu za operacje.
Kolejkowanie
Zdarzenia przyjmowane od razu, przetwarzane w tempie możliwym do obsłużenia. Chroni przed utratą danych przy szczycie. Prosty wariant: przepływ przyjmujący zdarzenie tylko je zapisuje, a drugi, uruchamiany harmonogramem, przetwarza to, co się nazbierało. Rozdzielenie przyjmowania od przetwarzania jest najskuteczniejszym zabezpieczeniem przed falą zdarzeń.
Zadania długotrwałe
Przepływ przekraczający limit czasu zostaje przerwany w połowie. Zadania długie trzeba dzielić — na partie obsługiwane kolejnymi uruchomieniami, ze znacznikiem, dokąd doszło poprzednie. Bez takiego znacznika po przerwaniu nie wiadomo, co zostało już zapisane, a co nie.
Sprawdzenie przy skali docelowej
Na liczbie zdarzeń odpowiadającej szczytowi, nie średniej. Sezon jest najgorszym momentem na odkrycie limitu. Warto policzyć obciążenie z góry: ile zdarzeń przypada na najbardziej ruchliwy dzień i ile wywołań generuje jedno zdarzenie po przemnożeniu przez kroki przepływu.
Gdy limitów nie da się obejść
Jeśli po podziale na partie i kolejkowaniu przepływ nadal nie mieści się w ograniczeniach, problem nie leży w ustawieniach. To sygnał, że zadanie przerosło narzędzie i należy do kodu albo do samego systemu — o czym mówi tekst o tym, kiedy przepływ staje się za duży. Sposób sprawdzania takich założeń przed uruchomieniem opisuje tekst o testowaniu przepływów.
