Уявіть: клієнт оплачує ваш курс або послугу. Гроші приходять на рахунок. Webhook спрацьовує. N8n починає свою магію — записати платіж у базу, надіслати email, оновити кабінет.
Але десь посередині щось йде не так. Можливо, база була недоступна — ми якраз оновлювали її. Можливо, ми не підібрали правильний час для deployment'у. Неважливо. Важливо інше: процес обірвався без сліду.
Результат? Гроші є (WayForPay підтвердив платіж). Але в нашій системі — нічого. Ніякого запису, ніякого email'а, нічого в особистому кабінеті клієнта.
Добре, що клієнт написав у підтримку. Ми розкопали логи, знайшли успішний платіж у провайдера, додали вручну. Але скільки таких "мовчазних" збоїв ми не помітили? Скільки клієнтів просто залишили негативний відгук десь у мережі, і ми навіть не дізналися чому?
Саме тоді я зрозумів: проблема не в n8n. Проблема в підході. Мені потрібен був не "виконувач завдань", а процесор, який пам'ятає стан і може повторити лише те, що впало. Не весь флоу знову. Тільки те, що не встигло завершитись.
Це не технологія підвела. Це архітектура мислення була неправильною.
Як працює n8n (і де він ламається)
N8n виконує ноди послідовно — одну за одною. Неважливо, як вони виглядають на canvas'і графічно. Важливо тільки одне: порядок виконання. Сигнал надійшов, нода 1 виконалась, нода 2 виконалась, нода 3...
Звучить логічно. Але ось проблема: якщо нода 2 впала з помилкою, ноди 3, 4, 5, 6 просто не виконаються. Процес зупиниться. І все.
Технічно, так, можна додати обробник помилок (Error Trigger) для кожної ноди. Але уявіть: у вас флоу з 10 кроків. Ви маєте додати 10 обробників помилок? Це вже не автоматизація — це джунглі.
Проблема не в помилках. Проблема в забутті.
N8n чудово з'єднує сервіси між собою — це його сила. Slack, Google Sheets, CRM, email — все працює "з коробки". Але є нюанс: n8n не знає, що процес десь обірвався. Він не зберігає контекст. Він не пам'ятає, що нода 1 і 2 вже виконались успішно, а нода 3 — ні.
Для нього кожне виконання — це окрема подія. Прийшов webhook, виконав що зміг, закрив завдання. Наступного разу він починає з нуля, ніби попередньої спроби не було.
Що це означає на практиці?
У нашому випадку з платежем сигнал надійшов успішно. Спроба записати в базу — помилка. Email не відправився. Кабінет не оновився.
N8n не знає, що треба повторити саме ці кроки. Він просто завершив виконання з помилкою і пішов далі. Процес втрачено. І якби клієнт не написав — ми б ніколи не дізналися.
Подієва vs процесна архітектура
N8n мислить подіями. Тригер спрацював, відреагував, забув. Успішно чи ні — неважливо. Контекст втрачено.
Основна проблема не в технології. Проблема в тому, що платіж — це не подія. Це процес.
Різниця між подією і процесом
Подія — це тригер. Щось сталося, потрібна реакція, все. Як доручення підлеглому: "Зроби це зараз", виконав, наступне завдання.
Процес — це інше. Це послідовність кроків зі станом. Платіж склався? Записано в базу? Email відправлено? Доступ наданий? Кожен крок залежить від попереднього, але вони можуть навіть виконуватись паралельно.
Чому це критично?
У реальному бізнесі дуже рідко є "одноразові" дії. Навіть те, що здається простим — доставка, платіж, реєстрація — насправді процеси з кількома станами.
Повернемось до нашого прикладу. Платіж складається з кроків: webhook прийшов від WayForPay, записати транзакцію в базу, надіслати email-підтвердження, надати доступ до курсу. Технічно, останні два кроки можна виконувати паралельно. Або навіть спочатку надати доступ, а потім відправити email — це звучить логічніше.
Але що, якщо запис у базу відпаде?
Тоді не має значення, у якому порядку виконувались інші кроки. У нас немає запису транзакції. А це означає, що ми не знаємо, що клієнт заплатив.
Ми не можемо показати йому історію платежів. При будь-якому конфлікті у нас немає доказів. І якщо email або доступ теж не спрацювали — клієнт взагалі в вакуумі.
N8n не бачить процесу. Він бачить події.
Для n8n кожен webhook — окрема подія. Він не знає, що крок 1 виконався успішно, що крок 2 впав, що кроки 3 і 4 взагалі не почалися. Він просто закрив виконання і пішов чекати наступного webhook'а.
Бізнес мислить процесами, а не подіями
Коли ви думаєте про платіж, ви не думаєте "прийшов webhook". Ви думаєте: "Клієнт заплатив, ми зафіксували, він отримав доступ, все добре". Це ланцюжок. Це стан, який змінюється. Це процес.
І якщо щось падає посередині — процес має продовжитись з того місця, де зупинився. Не починати знову. Не забувати, що вже зроблено. Саме цього n8n не вміє. Він не зберігає стан між кроками.
А що, якщо процес міг би зберігати свій стан? Саме це робить Temporal.
Temporal: коли процес пам'ятає себе
Уявіть, що кожен крок вашого процесу записується в журнал. Не просто "виконано" чи "помилка". А саме: що сталося, коли, і що треба зробити далі. Це і є Temporal.
Як це працює?
Temporal зберігає стан процесу в журналі подій (event log). По суті, це ті самі кроки, що і ноди в n8n. Але з однією критичною різницею: вони мають спільний контекст.
Кожен крок записує в журнал: "Webhook прийшов о 14:32", "Спроба записати в базу — помилка, база недоступна", "Email не відправлено (база недоступна, немає ID транзакції)". І Temporal не забуває про це.
Що відбувається при помилці?
База впала? Сервіс недоступний? Нічого страшного.
Temporal не закриває процес. Він зберігає журнал і чекає. Через хвилину, через годину — коли база знову доступна, Temporal відкриває журнал і каже: "Ага, мені треба завершити цей крок. База знову працює? Окей, продовжую."
І він виконує тільки те, що не встигло завершитись. Не весь процес заново. Тільки крок, що впав.
Той самий платіж, але в Temporal
Повернемося до нашого платежу. Ось як це виглядало б у Temporal.
Webhook прийшов — записано в журнал: "Процес почався. ID платежу: 12345. Клієнт: ivan@example.com. Сума: 500 грн."
Спроба записати в базу — помилка: "База недоступна. Повторити через 1 хвилину."
Повторна спроба через хвилину — успіх: "Транзакція записана. ID у базі: 987. Переходимо до наступного кроку."
Відправити email — "Email відправлено на ivan@example.com. Підтверджено."
Надати доступ до курсу — "Доступ наданий. Процес завершено."
Результат: Клієнт отримав все, що має. Ви бачите повну історію в журналі. Жодних "мовчазних" збоїв.
Процес не губиться. Він "засинає" і "прокидається"
Ключова відмінність: Temporal не закриває процес при помилці. Він його призупиняє.
N8n при помилці каже: "Ну, не вийшло. Бувай." Temporal каже: "Не вийшло зараз. Спробую пізніше." І він дійсно спробує. Автоматично. З того самого місця, де зупинився. Без вашого втручання.
Це не про складність. Це про надійність.
Так, Temporal складніший у налаштуванні, ніж n8n. Там немає drag-and-drop візуального редактора. Потрібно писати код. Але ціна помилки інша.
У n8n помилка означає втрачений процес. Ви дізнаєтесь, тільки якщо клієнт напише. У Temporal помилка означає призупинений процес. Система знає, що треба продовжити.
Для простих інтеграцій різниці немає. Але коли йдеться про гроші, дані клієнтів, критичні операції — процесне мислення обов'язкове. Не кожна автоматизація потребує Temporal. Але кожна критична операція — так.
Коли використовувати що?
Питання не в тому, що краще. Питання в тому, чи може ваша система пережити "мовчазний" збій.
Коли використовувати n8n
N8n підходить для інтеграцій між сервісами. Google Calendar з Calendly, новий файл на Google Drive обробити і перемістити, Slack-сповіщення на події в CRM, синхронізація даних між системами. Він також добрий для регулярних задач, де можна "доганяти". Щоденний імпорт файлів — якщо сьогодні впало, завтра оброблю два файли. Backup даних — пропустив один день, не критично. Розсилки, які можна повторити.
Критерій простий: якщо процес впав, і ви зможете "доганяти" наступного разу — n8n підійде.
Коли потрібен Temporal
Temporal потрібен для фінансових операцій. Платежі, виплати, транзакції — будь-що, де йдеться про гроші. Він також необхідний для бізнес-процесів, які не можна втратити. Реєстрація клієнта з створенням акаунту і доступом до продукту. Замовлення з обробкою і доставкою. Підписка зі списанням і продовженням доступу.
Критерій тут інший: якщо втрата процесу означає втрату грошей, клієнта або репутації — потрібен Temporal.
Просте правило
Запитайте себе: "Що станеться, якщо цей процес впаде посередині, і я не дізнаюсь?"
Якщо відповідь — "нічого страшного, наздожену пізніше", використовуйте n8n. Якщо відповідь — "клієнт втратить гроші, доступ або довіру", потрібен Temporal.
Не кожна автоматизація має бути антикрихкою. Але кожна критична операція — так.
Висновок
Інструменти не винні. Вони просто роблять те, для чого створені.
N8n — чудовий для швидких інтеграцій і прототипування. Temporal — для процесів, які ми не можемо втратити. Питання не в тому, що краще. Питання в тому, для чого ми їх використовуємо.
Я зрозумів це після того "загубленого" платежу. Проблема була не в n8n. Проблема була в тому, що я використовував інструмент для подій там, де потрібен був інструмент для процесів.
Тепер я ставлю собі просте питання: "Чи може ця система пережити збій без втрати контексту?"
Якщо так — n8n. Якщо ні — Temporal.
Не технологія визначає надійність. Розуміння природи процесу — визначає.
"Стабільність — це не відсутність збоїв, а здатність їх переживати, не втрачаючи пам'ять."
