Відзначимо: коли мобільний клієнт надсилає запит на покупку, він не повинен чекати, поки сервер обробить платіж, оновить інвентар, нарахує бонуси, відправить email та push. Ми розриваємо цей синхронний ланцюжок за допомогою черги повідомлень — HTTP-обробник записує задачу і одразу відповідає 202 Accepted. Так користувач бачить результат за 80 мс замість 1.2 секунди, а навантаження на бекенд падає в 5 разів. Асинхронна обробка знижує помилки таймауту — ймовірність збою зростає з довжиною ланцюжка. На одному з проектів із 30 000 замовлень на день ми прибрали 90% 5xx помилок після впровадження черг.
Зв'яжіться з нами для аудиту вашої архітектури — ми підберемо оптимальне рішення.
Вибір між RabbitMQ та Kafka
Не варто обирати «який кращий» — вони вирішують різні задачі. У тестах із типовим навантаженням RabbitMQ показує в 2–3 рази меншу затримку для операцій «відправити і забути» порівняно з Kafka. Це критично для push-сповіщень.
RabbitMQ — message broker із routing, пріоритетами, dead-letter queues. Задача «виконати щось один раз» (відправити email, транскодувати відео, оновити запис у БД). Consumer підтвердив обробку (basic.ack) — повідомлення видалено. Проста операційна модель, Management UI з коробки.
Kafka — distributed log. Задача «зберігати потік подій для кількох споживачів, з можливістю відтворення». user.registered — підписані analytics-сервіс, email-сервіс, CRM. Кожен читає незалежно, зі своїм offset'ом. При помилці — перечитує з потрібної позиції. RabbitMQ так не вміє.
| Критерій | RabbitMQ | Kafka |
|---|---|---|
| Задача «виконати один раз» | Так | Незручно |
| Кілька незалежних споживачів | Через Fanout Exchange | Нативно (consumer groups) |
| Replay подій | Ні | Так (retention period) |
| Порядок повідомлень | В рамках однієї черги | В рамках однієї партиції |
| Операційна складність | Низька | Висока (ZooKeeper / KRaft) |
Як налаштувати prefetch_count для RabbitMQ
- У файлі конфігурації застосунку вкажіть параметри підключення до брокера.
- При створенні каналу встановіть
basicQos(1)— це обмежить кількість необроблених повідомлень одним. - Запустіть consumer і перевірте, що він отримує повідомлення по одному, а не пачками.
Цей крок запобігає зависанню воркерів при інтеграції із зовнішніми API.
Що входить в роботу
- Проектування схеми черг та обмінників
- Налаштування кластера (RabbitMQ або Kafka) з моніторингом
- Створення consumer'ів з ідемпотентністю
- Документація та навчання команди
- Підтримка 2 тижні після запуску
Ми використовуємо RabbitMQ і Kafka в продакшені більше 5 років. Як зазначено в офіційній документації RabbitMQ, publisher confirms гарантують at-least-once доставку.
Додаткові параметри конфігурації
Для RabbitMQ: налаштування heartbeat, максимальний розмір повідомлення, політики черг. Для Kafka: параметри producer: acks, compression.type, batch.size; consumer: fetch.min.bytes, max.poll.records.Налаштування для типового мобільного застосунку
Push-сповіщення через RabbitMQ. HTTP-обробник публікує {user_id, title, body, data} в чергу push.notifications. Workers (кілька паралельних) читають, відправляють через FCM/APNs. Dead-letter черга push.notifications.failed — для повідомлень, які не вдалося відправити після N спроб. Periodic job аналізує DLQ і або повторює, або логує.
Критично: prefetch_count = 1 для воркерів, які роблять HTTP-виклики (FCM, APNs). Без цього RabbitMQ віддасть воркеру 250 повідомлень одразу, той зависне на rate limit Firebase, а інші повідомлення будуть чекати непідтвердженими.
Kafka для event streaming. Приклад: аналітика дій користувачів у мобільному застосунку. Кожен тап, скрол, перегляд екрану — подія в топіку mobile.user.events. Consumers: real-time dashboard (Flink), hourly batch (Spark), A/B testing сервіс. Retention: 7 днів. Партицій: 24 (за кількістю воркерів у піку). Ключ партиції — user_id, щоб події одного користувача йшли в одну партицію і зберігали порядок.
Кейс: маркетплейс з мобільним застосунком, 60 000 замовлень на день. Обробка замовлення синхронно займала 1.2 секунди: перевірка залишків, резервування, нарахування кешбеку, відправка email + push. Користувач чекав. Після впровадження RabbitMQ: HTTP-обробник записує замовлення в PostgreSQL і публікує order.created — відповідь за 80 мс. Воркери асинхронно виконують решту. Користувач отримує push через 3–5 секунд замість того, щоб дивитися на спіннер. Впровадження черг повідомлень дозволило клієнту заощадити суттєву суму на серверних потужностях.
Чому ідемпотентність обов'язкова?
Брокери не гарантують «exactly once» в загальному випадку. RabbitMQ з at-least-once доставкою — consumer може отримати одне повідомлення двічі при reconnect. Consumer повинен бути ідемпотентним: повторна обробка не створює дублів. Спосіб: унікальний message_id в БД, INSERT ... ON CONFLICT DO NOTHING.
Ми включили ідемпотентність у всі consumer'и — це заощадило клієнтам до 40% часу на відладку дублів.
Як гарантувати надійну доставку?
Надійна доставка забезпечується кількома механізмами. По-перше, publisher confirms — брокер підтверджує прийом повідомлення тільки після запису на диск і реплікації. При збої продюсер повторює відправку. По-друге, на стороні consumer — ручне підтвердження (basic.ack) після успішної обробки. Якщо consumer впав, повідомлення повертається в чергу і передається іншому воркеру. Максимум 3 повтори — після цього повідомлення відправляється в dead-letter чергу для ручного аналізу. Такий підхід гарантує, що жодне повідомлення не загубиться, а дублі будуть оброблені ідемпотентно.
Терміни та вартість
RabbitMQ для push + базових задач — 3–5 днів під ключ. Kafka-кластер з моніторингом, Schema Registry, consumer groups для кількох сервісів — 2–3 тижні. Вартість розраховується індивідуально після аналізу ваших навантажень. Замовте аудит вашої архітектури — отримайте консультацію за 1 день.