Гарантії порядку повідомлень

1) Що таке «порядок» і навіщо він потрібен

Порядок повідомлень - це відношення «що повинно бути оброблено раніше» для подій однієї сутності (замовлення, користувач, гаманець) або для всього потоку. Він важливий для інваріантів: «статус A перед B», «баланс до списання», «версія n перед n + 1».
У розподілених системах глобальний тотальний порядок доріг і рідко потрібен; зазвичай достатньо локального порядку «на ключ».

2) Види гарантій порядку

1. Per-partition (локальний порядок в розділі лога) - Kafka: порядок всередині партії зберігається, між партіями - ні.
2. Per-key (ordering key/message group) - всі повідомлення з одним ключем маршрутизуються в один «потік» обробки (Kafka key, SQS FIFO MessageGroupId, Pub/Sub ordering key).
3. Global total order - вся система бачить єдиний порядок (розподілений журнал/секвенсер). Дорого, погіршує доступність і throughput.
4. Causal order (причинно-наслідковий) - «подія B після A, якщо B спостерігає ефект A». Досяжний через метадані (версії, Lamport-часи/векторні годинники) без глобального секвенсера.
5. Best-effort order - брокер намагається зберігати порядок, але при збоях можливі перестановки (часто в NATS Core, RabbitMQ при декількох консюмерах).

3) Де порядок ламається

Паралельні консьюмери однієї черги (RabbitMQ: кілька consumers на одну чергу → interleaving).
Ретраї/повторні доставки (at-least-once), таймаути'ack', повторна постановка в чергу.
Ребаланс/фейловер (Kafka: переїзд партії/лідера).
DLQ/повторна обробка - «отруйне» повідомлення йде в DLQ, наступні йдуть далі → логічний розрив.
Мульти-регіон і реплікація - різні затримки → розсинхронізація.

4) Дизайн «порядку по ключу»

• Використовуйте природні ключі: `order_id`, `wallet_id`, `aggregate_id`.
• Слідкуйте за «гарячими ключами» - один ключ може «заблокувати» потік (head-of-line blocking). При необхідності розщеплюйте ключ: 'order _ id #shard (0.. k-1)'з детермінованою реконструкцією порядку на синці.
• У Kafka - один ключ → одна партія, порядок збережеться в межах ключа.

java producer.send(new ProducerRecord<>("orders", orderId, eventBytes));

(Ключ ='orderId'гарантує локальний порядок.)

5) «Порядок проти пропускної здатності»

• Один консюмер на чергу зберігає порядок, але знижує паралелізм.
• At-least-once + паралелізм підвищують продуктивність, але вимагають ідемпотентності та/або відновлення порядку.
• Global order додає hop до секвенсеру → ↑latentnost і ризик відмови.

Компроміс: per-key порядок, паралелізм = число партій/груп, + ідемпотентні синки.

6) Контроль порядку в конкретних брокерах

Kafka

Порядок всередині партії.
Дотримуйтесь'max. in. flight. requests. per. connection ≤ 5` с `enable. idempotence = true', щоб ретраї продюсера не змінювали порядок.
Консюмер-група: одна партія → один воркер в момент часу. Повторні доставки можливі → тримайте sequence/version в бізнес-шарі.
Транзакції (read-process-write) зберігають узгодженість «прочитав/записав/зкомітил офсети», але не створюють глобальний порядок.

properties enable.idempotence=true acks=all retries=2147483647 max.in.flight.requests.per.connection=5

RabbitMQ (AMQP)

Порядок гарантується на одній черзі для одного консюмера. З кількома консюмерами повідомлень може прийти «упереміш».
Для порядку: один консюмер або prefetch = 1 + ack по завершенні. Для паралелізму - розділяйте черги за ключами (sharding exchanges/consistent-hash exchange).

NATS / JetStream

NATS Core - best-effort, низька латентність, порядок може порушуватися.
JetStream: впорядкування всередині стріму/послідовності; при редоставках можливі перестановки на консюмері → використовуйте sequence і буфер відновлення.

SQS FIFO

Exactly-once processing (ефективно, за рахунок дедупа) і порядок всередині MessageGroupId. Паралелізм - кількістю груп, всередині групи head-of-line.

Google Pub/Sub

Ordering key дає порядок в межах ключа; при помилках публікація блокується до відновлення - стежте за backpressure.

7) Патерни збереження і відновлення порядку

7. 1 Sequence/версіонування

• приймає подію тільки якщо «seq = last_seq + 1»;
• інакше - кладе в буфер очікування до приходу відсутніх ('last _ seq + 1').

pseudo if seq == last+1: apply(); last++
else if seq > last+1: buffer[seq] = ev else: skip // дубль/повтор

7. 2 Буфери та вікна (stream processing)

Time-window + watermark: приймаємо out-of-order в межах вікна, по watermark «закриваємо» вікно і впорядковуємо.
Allowed lateness: канал для спізнілих (recompute/ignore).

7. 3 Sticky-routing по ключу

Хеш-маршрутизація'hash (key)% shards'відправляє всі події ключа в один воркер.
У Kubernetes - підтримуйте сесію (sticky) на рівні черги/шерди, не на L4-балансувальнику HTTP.

7. 4 Actor-модель/« один потік на ключ »

Для критичних агрегатів (гаманець): актор обробляє послідовно, решта паралелізм - кількістю акторів.

7. 5 Ідемпотентність + reordering

Навіть з відновленням порядку можливі повтори. Поєднуйте UPSERT за ключем + версії та Inbox (див. «Exactly-once vs At-least-once»).

8) Робота з «отруйними» повідомленнями (poison pills)

Збереження порядку стикається із завданням: «як жити, якщо одне повідомлення не обробити?»

Суворий порядок: блокування потоку ключа (SQS FIFO: вся група). Рішення - by-key DLQ: переводимо тільки проблемний ключ/групу в окрему чергу/ручний розбір.
Гнучкий порядок: допускаємо пропуск/компенсацію; логуємо і продовжуємо (не для фінансів/критичних агрегатів).
Політика ретраїв: обмежений'max-deliver'+ backoff + авідемпотентні ефекти.

9) Мульти-регіон і глобальні системи

Cluster-linking/реплікація (Kafka) не гарантує міжрегіональний глобальний порядок. Дайте пріоритет локальному per-key порядку і ідемпотентним синкам.
Для truly-global order використовуйте секвенсер (центральний лог), але це впливає на доступність (CAP: мінус A при мережевих розривах).
Альтернатива: causal order + CRDT для деяких доменів (лічильники, множини) - не потрібен строгий порядок.

10) Спостережуваність порядку

Метрики: `out_of_order_total`, `reordered_in_window_total`, `late_events_total`, `buffer_size_current`, `blocked_keys_total`, `fifo_group_backlog`.

11) Анти-патерни

Одна черга + багато консюмерів без шардування по ключу - порядок ламається відразу.
Ретраї через пере-пабліш в ту ж чергу без idempotency - дублі + out-of-order.
Глобальний порядок «про всяк випадок» - вибух латентності і вартості без реальної користі.
SQS FIFO одна група на все - повний head-of-line. Використовуйте MessageGroupId per ключ.
Ігнорування «гарячих ключів» - один «гаманець» гальмує все; діліть ключ на під-ключі там, де можливо.
Змішування критичних і bulk-потоків в одній черзі/групі - взаємний вплив і втрати порядку.

12) Чек-лист впровадження

• Визначено рівень гарантії: per-key/per-partition/causal/global?
• Спроектований ключ впорядкування і стратегія проти «гарячих ключів».
• Налаштований маршрутизатор: партіонування/MessageGroupId/ordering key.
• Консюмери ізольовані за ключами (sticky-routing, shard-workers).
• Включені ідемпотентність і/або Inbox/UPSERT на синках.
• Реалізований sequence/version і буфер reordering (якщо потрібно).
• Політика DLQ by key і ретраї з backoff.
• Метрики порядку і алерти: out-of-order, blocked_keys, late_events.
• Game day: ребаланс, втрата вузла, «отруйне» повідомлення, мережеві затримки.
• Документація: інваріанти порядку, межі вікон, вплив на SLA.

13) Приклади конфігурацій

13. 1 Kafka Consumer (мінімізація порушення порядку)

properties max.poll.records=500 enable.auto.commit=false  # коммит после успешной обработки батча isolation.level=read_committed

13. 2 RabbitMQ (порядок ціною паралелізму)

Один консюмер на чергу +'basic. qos(prefetch=1)`

bash rabbitmq-plugins enable rabbitmq_consistent_hash_exchange публикуем с хедером/ключом для консистентного хеша

13. 3 SQS FIFO

Задавайте MessageGroupId = key. Паралелізм = кількість груп.
MessageDeduplicationId для захисту від дублів (у вікні провайдера).

13. 4 NATS JetStream (ordered consumer, ескіз)

bash nats consumer add ORDERS ORD-KEY-42 --filter "orders.42.>" --deliver pull \
--ack explicit --max-deliver 6

14) FAQ

Q: Мені потрібен глобальний порядок?
A: Майже ніколи. Майже завжди достатньо per-key. Глобальний порядок - дорого і б'є по доступності.

Q: Як бути з «отруйним» повідомленням при строгому порядку?
A: Переводити тільки його ключ/групу в DLQ, інше - продовжувати.

Q: Чи можна отримати порядок і масштаб одночасно?
A: Так, порядок по ключу + багато ключів/партій + ідемпотентні операції і буфери reordering там, де потрібно.

Q: Що важливіше: порядок або exactly-once?
A: Для більшості доменів - порядок за ключем + ефективно exactly-once ефекти (ідемпотентність/UPSERT). Транспорт може бути at-least-once.

15) Підсумки

Порядок - це локальна гарантія навколо бізнес-ключа, а не дорога глобальна дисципліна. Проектуйте ключі і партії, обмежуйте «гарячі» ключі, використовуйте ідемпотентність і, де потрібно, sequence + буфер reordering. Слідкуйте за метриками «out-of-order» і «blocked keys», тестуйте збої - і ви отримаєте передбачувану обробку без жертв в продуктивності і доступності.