Капстоун очередей: собери pipeline обработки заказов

Спроектируй и собери end-to-end pipeline обработки заказов, который размещает заказ, разветвляет его на консьюмеры оплаты / склада / уведомлений, переживает краш на каждом хопе без двойного списания и без потери записи, отправляет poison-сообщения в карантин и показывает клиенту честный pending-then-confirmed UI — доказывая каждую гарантию намеренным failure-drill'ом, а не только happy-path демонстрацией.

• Сервис заказов с transactional outbox: в одной локальной транзакции БД INSERT строки заказа И строки outbox, описывающей order.placed. Покажи, что событие существует тогда и только тогда, когда существует заказ.
• Relay, отправляющий outbox-строки в Kafka at-least-once — начни с polling publisher (SELECT ... FOR UPDATE SKIP LOCKED, чтобы реплики не дублировали публикацию), затем подключи CDC (Debezium, читающий WAL, или outbox event router). Опиши, почему CDC — апгрейд, и чего он стоит операционно.
• Топики, ключуемые по order_id, чтобы события каждого заказа держали порядок по заказу на одной партиции; over-provision количества партиций и запиши, почему ты бы мигрировал на новый топик, а не менял размер на месте.
• Минимум две consumer groups (оплата, склад), которые коммитят оффсеты только ПОСЛЕ успеха хендлера и идемпотентны: dedup-ключ (event id) под уникальным ограничением внутри транзакции с side effect плюс Idempotency-Key, проброшенный в симулированный платёжный шлюз.
• Retry-с-backoff бюджет для транзиентных сбоев и dead-letter queue для poison-сообщений при исчерпании; покажи, что кривое событие попадает в DLQ, а не блокирует партицию, и что DLQ разгребаем.
• Eventual-consistent UI: checkout возвращает 202, UI показывает заказ как pending и сверяется до confirmed или failed по реальному событию — никогда фальшивый тост об успехе, с timeout-путём для так и не пришедшего подтверждения.
• Observability на швах: correlation id, проштампованный при записи заказа и пронесённый через каждый асинхронный хоп, плюс gauges для consumer lag, глубины DLQ, end-to-end задержки и slot lag CDC — с алертом на каждый.
• Failure-drill: убей консьюмер оплаты после side effect, но до коммита оффсета, и покажи отсутствие двойного списания; залипь CDC-консьюмер и покажи, что алерт на slot lag срабатывает до давления на диск; подай poison-сообщение и покажи, что оно достигает DLQ; переиграй из DLQ и покажи, что идемпотентность делает это безопасным.

• Диаграмма шести хопов (запись, публикация, маршрутизация, обработка, карантин, отображение) с подписью гарантии и защиты на каждом, совпадающая с тем, что реально делает твой код.
• Drill краша-до-коммита на консьюмере оплаты даёт ровно одно списание на один заказ — продемонстрировано логом запросов шлюза, а не утверждением.
• Poison-сообщение исчерпывает retry-бюджет и появляется в DLQ, пока остаток партиции продолжает течь; живой consumer lag не растёт без предела.
• Залипание CDC-консьюмера триггерит алерт на slot lag до того, как диск primary под угрозой, и max_slot_wal_keep_size задан так, что убежавший slot инвалидируется, а не фатален.
• UI показывает заказ как pending немедленно, никогда преждевременный успех, и сверяется до реального состояния; рефетч во время окна согласованности не стирает собственный заказ пользователя.
• Описание на одну страницу: где живёт каждая гарантия доставки, почему идемпотентность — несущий инвариант, и какие сбои твоя observability поймала бы в production.