Менеджери витрачають до 40% робочого часу на перенесення даних між складом, CRM та бухгалтерією. При ручному введенні виникає одна помилка на кожні 300 операцій — це втрачені замовлення та незадоволені клієнти. Щомісячні збитки від таких помилок сягають десятків тисяч гривень. Ми вирішуємо цю проблему раз і назавжди: налаштовуємо подійно-керовані ланцюжки webhook-автоматизації під ключ. Замовлення створено → миттєве резервування на складі → оновлення CRM → відправка трекінгу покупцю. Кожен крок незалежний, відмовостійкий і логується. Зв'яжіться з нами — ми покажемо, як це працює на вашому проєкті.
Які проблеми вирішуємо
Втрата webhook під час збоїв: HTTP-запит може не дійти через тайм-аут або перезавантаження сервера. Наше рішення — прийняти webhook миттєво (відповідь 200 OK за <50 мс), поставити задачу в чергу Redis та обробити асинхронно. Якщо обробка впаде, Laravel Horizon автоматично повторить спробу зі зростаючою затримкою. Дублювання замовлень: без ідемпотентності один клік створює три замовлення. Ми впроваджуємо unique-ключі та перевіряємо event_id у заголовку. Повторні webhook ігноруються. Різнорідні інтеграції: 1С, AmoCRM, Telegram — кожна система вимагає свого формату. Для цього використовуємо pipeline з Bus::chain і Bus::batch: один обробник синхронізує замовлення з усіма системами паралельно, а помилки йдуть у Dead Letter Queue. Складність налагодження без централізованого логування — неможливо зрозуміти, на якому кроці стався збій. Ми впроваджуємо структуроване логування в кожен обробник і налаштовуємо дашборди в Grafana.
Як ми це робимо: стек і кейс
Основний стек: Laravel 11 з PHP 8.3, Redis для черг, Horizon для моніторингу, Docker для контейнеризації. Кожен ланцюжок проектується як набір джоб — це спрощує налагодження та масштабування.
Ось приклад з нашої практики: для великого інтернет-магазину ми реалізували ланцюжок «Оплачене замовлення».
// обробник події order.paid public function onOrderPaid(array $payload): void { $order = Order::findByExternalId($payload['order']['id']); Bus::chain([ new MarkOrderAsPaid($order), new GenerateInvoice($order), new TriggerFulfillment($order), new SendPaymentConfirmation($order), ])->dispatch(); } Bus::chain гарантує послідовне виконання: якщо рахунок не згенерується, фулфілмент не запуститься. При помилці — ретрай з експоненціальним backoff і сповіщення в Telegram. Завдяки впровадженню цього ланцюжка, компанія заощадила значні кошти на ручному супроводі. Порівняння: Bus::chain в 2 рази надійніше послідовних HTTP-викликів при пікових навантаженнях — не блокує пул воркерів і зберігає стан у Redis. Докладніше про механізм можна прочитати в документації Laravel про черги.
Чому варто використовувати Laravel Horizon для моніторингу?
Horizon дає дашборд у реальному часі: затримка черги, кількість провалених завдань, швидкість обробки. Ми налаштовуємо алерти при перевищенні затримки >5 c і при досягненні 3 спроб — це дозволяє реагувати до того, як клієнти помітять проблему.
Що таке Dead Letter Queue і навіщо вона потрібна?
Dead Letter Queue (DLQ) — це черга для повідомлень, які не вдалося обробити після всіх спроб. Без DLQ ви просто втрачаєте інформацію про збій. Ми налаштовуємо автоматичне сповіщення в Telegram при потраплянні завдання в DLQ. Це дозволяє оперативно розібратися з причиною та відновити дані.
Порівняння: черги та ланцюжки
Порівняння типів черг
| Черга | Продуктивність | Надійність | Складність налаштування | Краще для |
|---|---|---|---|---|
| Redis (через Horizon) | ~10 000 завдань/с | Висока (AOF) | Низька | Більшості проєктів |
| RabbitMQ | ~100 000 завдань/с | Дуже висока (кластер) | Середня | Високонавантажених систем |
| База даних (MySQL) | ~1000 завдань/с | Середня | Мінімальна | Прототипів і малих навантажень |
Порівняння ланцюжків для різних подій
| Подія | Обробники (Bus::batch/chain) | Ключова особливість |
|---|---|---|
| Замовлення створено | Резервування, CRM, сповіщення складу | Паралельне виконання, allowFailures() |
| Оплачено | Статус, інвойс, фулфілмент, SMS | Послідовне, строгий порядок |
| Скасовано | Повернення резерву, CRM, повернення оплати | Ідемпотентність — другий виклик ігнорується |
Процес роботи
- Аналітика — вивчаємо бізнес-процеси та точки інтеграції.
- Проектування — малюємо схему ланцюжків і обираємо чергу (Redis, RabbitMQ).
- Реалізація — пишемо обробники, middleware для перевірки підпису, pipeline.
- Тестування — моделюємо відмови та перевантаження; емуляція падінь зовнішніх сервісів.
- Деплой — налаштовуємо CI/CD, логування, Horizon.
Строки та вартість
Строк реалізації типового проєкту — від 2 до 4 тижнів. Складні інтеграції — до 6 тижнів. Вартість розраховується індивідуально після аудиту поточної архітектури.
Чек-лист і типові помилки
Чого уникати:
- Обробка webhook синхронно — блокує сервер.
- Ігнорування перевірки підпису — вразливість для CSRF.
- Занадто малий retry limit — втрата замовлень.
- Відсутність Dead Letter Queue — не побачите провали.
Типові помилки:
- Webhook приходить, але не обробляється: перевірте, чи не заблоковано endpoint фаєрволом. Переконайтеся, що черга запущена (php artisan horizon). Подивіться failed_jobs — можливо, завдання впало з винятком.
- Невірний payload: використовуйте валідацію та логування вхідних даних.
Висновок
Автоматизація ланцюжків webhook — це не тільки швидкість, але й надійність. Замовте налаштування — ми проведемо аудит, спроектуємо архітектуру та реалізуємо під ключ. Отримайте консультацію — розповімо, як прискорити обробку замовлень у 3 рази.