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