Порядок сообщений: полный порядок — налог на throughput, частичный — честная сделка

Сервис кошелька шлёт balance.credit, затем balance.debit по одному аккаунту. В staging, с одним consumer, это работает месяцами. В prod ты масштабируешь до восьми consumers ради throughput — и debit прилетает первым: клиент на миг уходит в минус, срабатывает антифрод-правило, аккаунт замораживают. В коде ничего не менялось. Ты просто убрал случайную однопоточную упорядоченность, которую staging давал бесплатно, и обнаружил, что очередь и не обещала порядок между consumers.

У полного порядка ровно одна форма, и она медленная

«Обрабатывать всё ровно в том порядке, в котором произвели» звучит как флаг в конфиге. Это не так. Единственный способ получить единую глобальную последовательность — единственная точка сериализации: одна partition, записанная одним порядком producer, вычитываемая одним consumer за раз. Как только два consumers могут работать параллельно, единого таймлайна больше нет — сообщения 5 и 6 гонятся, и побеждает тот handler, что закончит первым. Полный порядок и параллелизм физически противоположны: нужный тебе порядок — это очередь из одного.

В этом и есть налог на throughput. SQS FIFO с одной message group упирается в 300 сообщений/секунду (3 000 с батчингом по 10), потому что всё в одной группе выдаётся по одному за раз — SQS не отдаст следующее сообщение группы, пока предыдущее не удалено. Kafka с одной partition ограничен throughput этой единственной partition и одним consumer в группе; добавление consumers не помогает, потому что partition назначается ровно одному consumer. Полный порядок ты купил своей масштабируемостью.

Частичный порядок — это то, что тебе на самом деле нужно

Прозрение сеньора в том, что полный порядок над всем почти никогда не нужен — нужен порядок внутри сущности. Кошельку всё равно, упорядочен ли credit аккаунта A относительно debit аккаунта B; они независимы. Ему критично, чтобы события самого A оставались в последовательности. Это и есть частичный порядок: сообщения с одним ключом FIFO друг относительно друга, а разные ключи свободно параллелятся.

Именно эту модель дают обе крупные системы:

• Kafka упорядочивает внутри partition. Выбери ключ partition (id аккаунта), и Kafka хэширует его в partition; все события этого ключа попадают в одну partition, по порядку, на полном throughput partition. Разные ключи разбросаны по partitions и consumers.
• SQS FIFO упорядочивает внутри MessageGroupId — порядок строго в пределах группы, никогда между группами. Одна группа = строгий FIFO и выдача по одному; разные группы обрабатываются параллельно. Поэтому совокупный throughput растёт с числом message groups: high-throughput режим достигает десятков тысяч сообщений/секунду только за счёт распределения нагрузки по многим группам и батчинга, а не ускорения отдельной группы.

Выбери ключом сущность, которая должна оставаться согласованной — на аккаунт, на агрегат, на пользователя — и получишь порядок ровно там, где он важен, и параллелизм везде остальном.

Как порядок тихо ломается в проде

Частичный порядок не бесплатен — он держится, лишь пока истинны три вещи, и прод обожает ломать каждую.

1. Ты добавляешь partitions. Kafka сопоставляет ключ с partition хэшем по модулю числа partitions. Увеличь partitions с 6 до 12 — и тот же ключ теперь хэшится в другую partition. События ключа в полёте всё ещё вычитываются из старой partition, пока новые валятся в новую — на какое-то окно две partitions держат события одного ключа, и два consumers обрабатывают их параллельно. Репартиционирование — классическое событие порчи порядка; поэтому команды закладывают partitions с запасом наперёд, а не растят их.

2. Ретраи и DLQ вставляют сообщения вне очереди. Handler падает на сообщении 5, оно уходит в dead-letter queue, и позже кто-то его реплеит — но сообщения 6, 7, 8 уже закоммичены. Теперь 5 прилетает после своих преемников. Даже внутри одной partition ретрай, переотправляющий в хвост, переупорядочивает относительно всего, что произвели за это время. Реплей DLQ на полной скорости тоже переупорядочивает целый батч относительно живого трафика — поэтому реплеят с ограничением скорости, а не всё разом.

3. Producer переупорядочивает под ретраем. Этот кусает у источника. В Kafka, если enable.idempotence равно false, а max.in.flight.requests.per.connection больше 1, упавший и ретраящийся батч может приземлиться после более позднего, который успел — тихо меняя местами два сообщения в одной partition. KIP-185 сделал идемпотентный producer дефолтом именно чтобы это закрыть: брокер ведёт sequence number на producer и partition, отбрасывает дубликаты и отвергает батчи вне последовательности, сохраняя порядок даже при до 5 запросах в полёте.

Паттерны, которые делают порядок переживаемым

Сделать распределённую систему идеально упорядоченной дёшево нельзя, поэтому сеньоры проектируют так, чтобы эпизодический беспорядок был безвреден. Четыре хода, примерно по убыванию рычага:

1. Партиционируй по сущности, которой нужен порядок. Выбери ключом границу согласованности — accountId, id агрегата, userId. Это фундамент; остальные три закрывают оставленные им зазоры.
2. Сделай handler идемпотентным. Сохраняй id сообщения (или ключ идемпотентности) и пропускай всё, что уже видел. Теперь at-least-once передоставка — это no-op вместо двойного списания, а реплей DLQ безопасен.
3. Делай эффекты коммутативными, где можешь. Если операция — set balance = X, а не add X, порядок перестаёт иметь значение — побеждает последняя запись, и повторное применение безвредно. Коммутативные или last-write-wins эффекты превращают проблему порядка в не-проблему.
4. Носи sequence number / version и отбрасывай устаревшие апдейты. Штампуй каждое событие монотонной версией на сущность; consumer помнит наивысшую применённую версию и выбрасывает всё ниже. Апдейт вне порядка или реплейнутый — детектируется и дропается. Это single-flight на ключ плюс проверка версии — сильнейшая защита, когда эффекты не коммутативны.