Очереди, потоки, события
Капстоун очередей: тест с выбором ответа
Шесть вопросов поперёк всего трека очередей. Ни один не про определение для заучивания — каждый отражает решение, которое ты принимаешь, проектируя или отлаживая один pipeline обработки заказов, где outbox, Kafka, CDC, DLQ и UI обязаны договориться между собой.
Убедись, что держишь весь pipeline в голове целиком: где живёт каждая гарантия доставки, почему упорядочивание по ключу хрупкое и почему один инвариант — идемпотентность — делает безопасным каждый хоп.
По всему pipeline заказа — запись в outbox, публикация через CDC, доставка Kafka, обработка консьюмером — какой единственный инвариант делает систему корректной end-to-end и почему?
Хендлер заказа должен и сохранить заказ, и эмитить order.placed. Почему transactional outbox — правильная форма, а не INSERT-затем-kafka.publish в одном хендлере?
Топик заказов ключуется по order_id, 6 партиций. В горячую пятницу лаг скачет, и кто-то поднимает его до 12 партиций. Что ломается и почему?
Консьюмер оплаты тянет order.placed, вызывает Stripe, успешно, затем под убит до коммита Kafka-оффсета. Группа перебалансируется и делает replay оффсета. Как не допустить двойного списания?
Ты используешь CDC (Debezium, читающий WAL) как relay для outbox. Воркер Kafka Connect получает OOM и лежит часами. В чём production-риск и какой guardrail?
POST на checkout возвращает 202 Accepted за 40мс; консьюмер пишет заказ примерно через 700мс. UI показывает тост об успехе и сразу рефетчит список заказов. Что увидит пользователь и какой честный дизайн?
Весь трек схлопывается в одно дерево решений: запись заказа атомарна, потому что строка и её outbox-событие коммитятся в одной локальной транзакции; CDC (или polling-relay) публикует at-least-once, возобновляясь со своего log offset — а slot это заряженное ружьё, на которое надо алертить и которое надо capить; топик хранит порядок по ключу через ключевание на order_id, поэтому поднятие количества партиций — дверь в одну сторону, рехеширующая ключи; consumer group доставляет at-least-once, коммитя оффсеты только после обработки; poison-сообщения, исчерпавшие retry-бюджет, идут в DLQ, а не блокируют партицию; и UI говорит правду об окне согласованности через optimistic-then-pending состояние. Нить через всё это — идемпотентность: dedup-ключ под уникальным ограничением плюс Idempotency-Key, проброшенный во внешние вызовы, потому что каждый честный хоп — at-least-once, и дубли это контракт, а не баг.