Kategoria: Automatyzacja i autonomia
„Mamy to zautomatyzowane: bot pobiera załącznik z poczty i zapisuje go na dysku sieciowym, a skrypt przepisuje wiersze z arkusza do systemu księgowego”. Takie zdanie opisuje transport danych między dwoma miejscami. Automatyzacja procesu zaczyna się o jeden krok dalej, przy decyzji, kto wyznacza moment uruchomienia.
Opisuję jedną instancję n8n uruchomioną na własnym serwerze domowym, z bazą PostgreSQL pod spodem i własnymi usługami w Pythonie obok niej. Liczby poniżej pochodzą z trzech odczytów z tej maszyny: bloków wyzwalaczy z bazy n8n z 29 października 2026, dziennika przebiegów z 30 października 2026 oraz plików docker compose z 2 listopada 2026. Są to odczyty z tych dni, nie pomiary tempa pracy.
Skrypt przenosi dane, zdarzenie przenosi decyzję o momencie
Co znaczy integracja punkt-punkt
Integracja punkt-punkt to połączenie, w którym jedna strona zna adres drugiej i sama po niego sięga. Skrypt wie, skąd pobrać plik i gdzie go odłożyć, a o tym, kiedy to zrobić, decyduje zegar albo kliknięcie. Dopóki obie strony odpowiadają tak samo jak w dniu konfiguracji, układ pracuje i nie wymaga nadzoru.
Kłopot nie polega na tym, że takie połączenie się psuje, bo psuje się każde. Polega na tym, że przerwanego przebiegu nie ma kto podnieść: zatrzymuje się w połowie i zostawia jeden wiersz w dzienniku. Ile takich wierszy zbiera się w dwa tygodnie, policzyłem osobno, czytając dziennik przebiegów własnej instancji n8n.
Zegar sprawdza na ślepo, zdarzenie zgłasza się samo
Cena jednego i drugiego rozwiązania
Harmonogram pyta o stan bez względu na to, czy cokolwiek się zmieniło, i w większości przebiegów nie znajduje nic nowego. Jest przy tym najprostszy do skonfigurowania i najtrudniejszy do zepsucia: nie wymaga adresu widocznego z zewnątrz ani niczego po drugiej stronie.
Webhook jest odwrotnością tego układu. Nie sprawdzam niczego, ponieważ o zmianie informuje mnie druga strona, a opóźnienie spada z „do następnego sprawdzenia” do ułamka sekundy. Cena siedzi w utrzymaniu: adres musi pozostać dostępny i musi być zabezpieczony, bo w przeciwnym razie automatyzację uruchomi każdy, kto go zna. Samego opóźnienia nie zmierzyłem, więc podaję tu różnicę rodzaju, nie liczbę milisekund. Trzy pytania, według których wybieram wyzwalacz, zestawiłem osobno: harmonogram, webhook czy czat.
Kto wyznacza moment w moich 223 workflow
Trzysta trzydzieści cztery bloki w czterech grupach
Odczyt z 29 października 2026 znalazł w bazie 223 workflow i 334 bloki wyzwalaczy. Suma przekracza liczbę workflow, ponieważ jeden workflow często zawiera dwa bloki: właściwy oraz ręczny, pozostawiony po testach. Pogrupowałem je według tego, kto wyznacza moment uruchomienia.
| Grupa wyzwalaczy | Liczba bloków | Kto wyznacza moment |
|---|---|---|
| człowiek: czat, Telegram, ręczne uruchomienie | 102 | ja |
| druga strona: webhook, arkusz, dysk | 90 | system, który zgłasza zmianę |
| inna automatyzacja: wywołanie z sąsiedniego workflow | 79 | workflow nadrzędny |
| zegar: harmonogram | 63 | ustalona godzina |
| razem | 334 |
Na sygnał z zewnątrz czeka 90 bloków z 334, a zatem nieco ponad czwarta część. Mój własny system pozostaje więc w większości zegarowy i ręczny, i to jest uczciwy punkt wyjścia dla każdego, kto słyszy hasło o architekturze zdarzeń. Co znaczy sama liczba 223 i ile z tych pozycji jest włączonych, rozłożyłem osobno: ponad 150 workflow w n8n.
Orkiestrator nasłuchuje, własne usługi liczą
Sześć usług w jednym pliku
W pliku docker compose odczytanym 2 listopada 2026 na wspólną pulę połączeń wskazuje sześć usług: n8n, digital-twin-api, db-event-bridge, eda-orchestrator, db-backup i infra-sentinel. Nazwy opisują podział pracy: n8n czeka na sygnał i kieruje ruchem, jedna usługa zamienia zmianę w bazie na zdarzenie, druga prowadzi dłuższe sekwencje, pozostałe pilnują stanu i kopiują dane. Jak zbudowane jest to wspólne wejście do baz, opisałem przy konfiguracji puli połączeń.
Logika, której nie chcę trzymać w blokach narzędzia wizualnego, stoi właśnie w tych usługach. To mój własny kod, w jednej przypiętej wersji Pythona, odtwarzalny z jednego pliku razem z dziewięcioma projektami docker compose i 32 kontenerami; miesiąc, w którym doprowadziłem maszynę do tego stanu, opisałem przy wnioskach z konferencji o budowie oprogramowania. Ten odczyt mówi jednak tylko, co jest zadeklarowane. Nie mówi, ile z tego wytrzyma awarię.
Odporność nie jest stanem, jest ustawieniem bloku
Co pokazał dziennik przebiegów
Dziennik przebiegów z czternastu dni, od 16 do 30 października 2026, zawiera 5 245 wierszy: 4 200 udanych, 1 044 z błędem i jeden oczekujący. Udział błędów wynosi 19,9 % i rozkłada się na 31 różnych workflow ze 119 włączonych. Żaden z tych nieudanych przebiegów nie został powtórzony automatycznie, ponieważ w n8n ponowienie jest ustawieniem pojedynczego bloku i domyślnie pozostaje wyłączone.
Wniosek waży dla mnie więcej niż sam wskaźnik: architektura oparta na zdarzeniach nie daje odporności w prezencie. Ponowienie pomaga tam, gdzie operację wolno powtórzyć bez skutków ubocznych, i szkodzi wszędzie tam, gdzie blok coś zmienia, bo trzykrotnie wysłana wiadomość to u odbiorcy trzy wiadomości. Jedyna rzecz, która podniosła się u mnie sama, siedzi warstwę niżej: po restarcie PostgreSQL około godziny 10:24 pula zapisała cztery zerwane połączenia i zestawiła je ponownie bez mojego udziału. Jest to jedno okno jednego dnia, nie miara niezawodności.
Kiedy skrypt punkt-punkt wystarcza
Najtańszy wyzwalacz, który załatwia sprawę
Kolejność pytań pozostaje u mnie zawsze ta sama. Jeżeli druga strona potrafi zawołać, wybieram webhook. Jeżeli opóźnienie kilku godzin niczego nie psuje, wybieram zegar, bo utrzymuję go taniej. Jeżeli zadanie ma sens wyłącznie wtedy, gdy sam o nie poproszę, zostaje okno czatu. Architektura zdarzeń zarabia na siebie w dwóch miejscach: tam, gdzie reakcja w ciągu sekund ma wartość, i tam, gdzie samo sprawdzanie kosztuje więcej niż obsługiwana sprawa.
Druga granica dotyczy tego, co po drugiej stronie można w ogóle wywołać. Automatyzacja, która czyta ekran, czeka na obraz; ta, która wywołuje interfejs, czeka na odpowiedź. Tę różnicę rozłożyłem osobno: interfejs czy ekran.
Co te liczby pomijają
Pięć rzeczy, których te odczyty nie obejmują
- Zliczam bloki, nie uruchomienia. Jeden workflow z dwoma wyzwalaczami stoi w tabeli dwukrotnie, stąd 334 przy 223 pozycjach w bazie.
- Opóźnienia nie zmierzyłem. Różnica między zegarem a webhookiem jest tu różnicą rodzaju i nie podaję jej w milisekundach.
- Udział błędów opisuje czternaście dni, bo tyle historii przechowuje moja instancja. Porównania rok do roku z tych danych nie będzie.
- Sześć usług to wpisy w pliku konfiguracyjnym. Odczyt pokazuje, co jest zadeklarowane, a nie jak te usługi zachowają się pod obciążeniem.
- Nie jest to miara oszczędzonego czasu. Nie mam takiej liczby dla żadnej ze swoich dziedzin i ten odczyt jej nie przybliża.
Którą warstwą tego układu są same dane, opisałem przy cyfrowym bliźniaku, a to, co dokładnie jest uruchomione w kontenerze z n8n, przy jego konfiguracji w Dockerze.
