Когда система перестаёт жить только в модели "клиент отправил запрос - сервер сразу ответил", почти всегда появляются асинхронные взаимодействия. Нужно отправить письмо позже, пересчитать отчёт в фоне, обработать оплату, отдать событие в аналитику, синхронизировать данные между сервисами. Вот здесь в архитектуре часто появляются брокеры сообщений вроде Kafka и RabbitMQ.
Для QA это очень важная тема, потому что дефекты в асинхронных системах выглядят особенно коварно. Пользователь уже увидел "успех", а фоновая обработка ещё не закончилась. Сообщение могло потеряться, задублироваться, обработаться не тем consumer, прийти позже, чем ожидалось, или застрять в очереди. Если тестировщик мыслит только request-response моделью, такие баги будут постоянно ускользать.
Что общего у Kafka и RabbitMQ
И Kafka, и RabbitMQ помогают передавать сообщения между компонентами системы без жёсткой синхронной связки.
- →producer отправляет сообщение
- →брокер принимает его
- →consumer потом читает и обрабатывает
Это позволяет разделить систему на части, которые меньше зависят друг от друга по времени. Один сервис не обязан ждать, пока второй немедленно ответит и закончит всю работу.
Для QA это означает, что часть продукта живёт не в одном запросе, а во времени. И проверять нужно уже не только "пришёл ли ответ", но и "что случилось потом".
Чем Kafka отличается от RabbitMQ
Хотя обе технологии работают с сообщениями, по смыслу они ближе к разным сценариям.
Kafka обычно используют как event streaming platform. У неё сильный акцент на поток событий, долговременное хранение сообщений, работу с большими объёмами данных и независимое чтение этих событий разными consumer. Сообщения хранятся в topic, а consumer читают их по offset.
RabbitMQ чаще воспринимается как классический message broker. Он хорошо подходит для очередей задач, routing, work queues, publish/subscribe сценариев и управляемой доставки сообщений между producer и consumer.
- →Kafka сильнее там, где важен поток событий и повторное чтение
- →RabbitMQ сильнее там, где важна гибкая маршрутизация и классические очереди задач
Для QA это важно не ради архитектурного снобизма, а потому что разные модели создают разные классы дефектов.
Что особенно важно QA
Как только в системе появляется брокер сообщений, нужно перестать думать только категорией "запрос завершился". Теперь важны ещё и такие вопросы:
- →сообщение вообще было опубликовано?
- →его получил нужный consumer?
- →оно обработалось один раз или несколько?
- →не потерялось ли оно по дороге?
- →что происходит при ошибке обработки?
- →есть ли retry?
- →есть ли dead-letter queue или аналогичная зона отказов?
- →сохраняется ли порядок там, где он важен?
- →что видит пользователь до завершения фоновой обработки?
- →как система ведёт себя при лаге, задержке и всплеске нагрузки?
Очень много багов в таких системах не выглядят как "ошибка API". Они выглядят как странное рассинхронизированное поведение продукта.
Kafka глазами QA
Для QA в Kafka особенно важно понимать несколько базовых вещей.
- →Kafka хранит события как журнал
- →одно и то же событие могут читать разные consumer для разных задач
- →особенно важны порядок, ретенция, consumer lag и повторное чтение
Для QA это значит, что нужно внимательно смотреть на идемпотентность и на то, как система переживает повторы и задержки.
RabbitMQ глазами QA
В RabbitMQ для QA особенно важны другие вещи.
- →очереди
- →exchange и routing
- →acknowledgements
- →requeue
- →dead-letter behavior
- →publisher confirms
- →конкурирующие consumer
RabbitMQ очень хорош в сценариях, где сообщения нужно гибко маршрутизировать, а задачи - распределять между worker'ами.
Где чаще всего ломается
- →сообщение не опубликовано вообще
- →сообщение опубликовано дважды
- →consumer обработал его повторно
- →сообщение застряло в очереди
- →обработка прошла частично
- →порядок событий нарушился
- →событие пришло позже, чем ожидает UI или downstream-сервис
- →retry создал дубликаты данных
- →dead-letter queue начала наполняться, а продукт этого не показывает
- →пользователь видит "успех", хотя фоновая часть ещё не завершилась
Для QA это означает, что проверка таких систем почти всегда должна включать не только интерфейс, но и логику доставки, лаг, очереди, статусы обработки и итоговое состояние данных.
Практический пример
Представь оформление заказа.
Пользователь нажимает кнопку, API быстро возвращает успех, но дальше в фоне должны произойти ещё несколько действий:
- →создать платёжное событие
- →отправить письмо
- →обновить склад
- →отдать данные в аналитику
В синхронной системе всё это можно было бы ждать в одном запросе. В асинхронной системе часть шагов уходит через брокер сообщений.
Что важно QA:
- →событие заказа действительно опубликовано
- →каждый нужный consumer его получил
- →сбой письма не ломает биллинг
- →повторная доставка не создаёт два письма, два списания или два заказа
- →пользовательский статус заказа отражает реальное состояние обработки
- →при сбое сообщения не исчезают молча
Вот здесь и становится видно, почему простого UI-теста недостаточно.
Что должен вынести QA из этой темы
- →Kafka и RabbitMQ обе работают с сообщениями, но обычно решают разные архитектурные задачи.
- →В асинхронных системах нельзя мыслить только моделью request-response.
- →Для QA особенно важны повторы, задержки, порядок, retry, dead-letter и идемпотентность.
- →Большая часть проблем в messaging-системах выглядит как рассинхронизация, а не как "обычная ошибка API".
- →Хорошая проверка таких сценариев всегда смотрит не только на факт отправки, но и на итог обработки.
Что ещё почитать
- →Внутри базы: Negative API testing
- →Внутри базы: Contract testing
- →Внешний материал: RabbitMQ tutorials