Налаштування чергу повідомлень (RabbitMQ/Kafka) для мобільного додатку
Коли мобільний клієнт надсилає запит на покупку, він не повинен чекати, поки сервер обробить платіж, оновить інвентар, нараховуватиме бонуси, надішле email та сповіщення. Черги повідомлень розривають цей синхронний ланцюг — обробник HTTP записує завдання та відразу повертає 202 Accepted.
RabbitMQ або Kafka — як вибрати
Не потрібно вибирати один «кращий» — вони вирішують різні завдання.
RabbitMQ—message broker з маршрутизацією, пріоритетами та dead-letter черги. Завдання: «виконати щось один раз» (надіслати email, перекодувати відео, оновити запис БД). Consumer підтверджує обробку (basic.ack)—повідомлення видаляється. Проста операційна модель, Management UI в комплекті.
Kafka—розподілений event log. Завдання: «зберігати потік подій для кількох consumers із можливістю відтворення». user.registered—підписані analytics, email та CRM сервіси. Кожен читає незалежно зі своїм offset'ом. На помилку—перечитує з правильної позиції. RabbitMQ не вміє так.
| Критерій | RabbitMQ | Kafka |
|---|---|---|
| Виконати задачу один раз | Так | Незручно |
| Кілька незалежних consumers | Через Fanout Exchange | Нативно (consumer groups) |
| Відтворення подій | Ні | Так (retention period) |
| Порядок повідомлень | У межах однієї черги | У межах однієї партиції |
| Операційна складність | Низька | Висока (ZooKeeper / KRaft) |
Конфігурація для типового мобільного додатку
Push-сповіщення через RabbitMQ. HTTP обробник публікує {user_id, title, body, data} у чергу push.notifications. Workers (паралельні екземпляри) споживають, надсилають через FCM/APNs. Dead-letter черга push.notifications.failed—для повідомлень, які не вдалось надіслати після N спроб. Періодичне завдання аналізує DLQ і або повторює, або логує.
Критично: встановіть prefetch_count = 1 для воркерів, що роблять HTTP дзвінки (FCM, APNs). Без цього RabbitMQ доставляє 250 повідомлень одночасно; воркер потрапляє на rate limit Firebase і зависає, тоді як повідомлення чекають непідтвердженими.
Kafka для event streaming. Приклад: відстеження дій користувача у мобільному додатку. Кожен тап, скролл, перегляд екрана — подія у топіку mobile.user.events. Consumers: real-time dashboard (Flink), погодинний batch (Spark), сервіс A/B тестування. Retention: 7 днів. Партиції: 24 (за кількістю воркерів на піку). Ключ партиції: user_id, забезпечуючи упорядкування подій одного користувача в одній партиції.
Реальний приклад: маркетплейс із мобільним додатком, 60 000 замовлень на день. Синхронна обробка замовлення займала 1.2 секунди: перевірка залишків, резервування, нарахування кешбеку, відправлення email + push. Користувачі чекали. Після впровадження RabbitMQ: HTTP обробник записує замовлення в PostgreSQL і публікує order.created—відповідь за 80ms. Воркери асинхронно виконують решту. Користувачі отримують push за 3–5 секунд замість того, щоб дивитися на спіннер.
Ідемпотентність — обов'язкова вимога
Брокери не гарантують «exactly once» загалом. RabbitMQ з доставкою «at-least-once» означає, що consumer може отримати повідомлення двічі при переconnect'і. Consumers повинні бути ідемпотентними: повторна обробка не створює дублів. Метод: унікальний message_id у базі даних, INSERT ... ON CONFLICT DO NOTHING.
Час реалізації: RabbitMQ для push + базові завдання — 3–5 днів. Kafka кластер з моніторингом, Schema Registry, consumer groups для кількох сервісів — 2–3 тижні.