Заказ создали, а через минуту отменили. Оба события опубликованы корректно. Но система доставки почему-то получила отмену раньше создания. Если обработчик бездумно применит их в порядке прибытия, отменённый заказ рискует снова стать активным.
В распределённой системе момент возникновения события, публикации и обработки — разные вещи. Поэтому порядок, который человеку кажется естественным, нужно отдельно оговаривать и обеспечивать.
Порядок чего именно нам нужен?
Для одного заказа важно, чтобы состояние «отменён» не перезаписывалось более старым «создан». Но вовсе не обязательно заставлять заказы двух независимых покупателей обрабатываться строго друг за другом. Такая глобальная последовательность снижает параллелизм и превращает поток в узкое место.
Обычно разумная граница порядка — один заказ, счёт или другой бизнес-объект. Сообщения направляют по общему ключу или присваивают версиям последовательные номера. Конкретный брокер может гарантировать порядок внутри партиции или группы сообщений, но не для всего мира.
Очередь может доставить по порядку, обработчик — закончить иначе
Даже если сообщения получены последовательно, параллельная обработка может завершиться не по порядку. Первая задача ждала внешнего сервиса, вторая закончила быстро. Поэтому важны правила выполнения и подтверждения, а не только настройки транспорта.
Версии состояния помогают распознать устаревшее обновление. Вместо слепой перезаписи можно проверить, к какой версии объекта относится событие, и отклонить старую операцию или отправить её на восстановление.
Чем приходится платить за строгий порядок
Обработка в одной последовательной группе ограничивает её пропускную способность. Если одна запись постоянно падает, следующие события того же ключа могут ждать. Нужно понимать, когда разрешена параллельность, как обходить проблемные сообщения и какие задержки приемлемы.
Перекладывать глобальную синхронизацию на брокер ради простой аналитики часто бессмысленно. Независимые показатели можно считать параллельно, а агрегаты корректировать по версиям или времени события.
Решение начинается с бизнес-ошибки
Прежде чем включать строгий порядок, я бы попросил пример неправильного результата: дважды выдали товар, отменённый заказ снова ожил, неверно посчитали баланс. Затем выяснил, достаточно ли упорядочивания по одному объекту и проверки версий на стороне потребителя.
Порядок нужен не потому, что события «по идее должны идти подряд». Он нужен там, где нарушение последовательности меняет реальное состояние бизнеса.