Очереди, потоки, события
Change data capture: тест на воспроизведение
Воспроизведение бьёт перечитывание. Для каждого промпта проговори или запиши полный ответ по памяти прежде, чем открыть модельный — именно усилие припоминания закрепляет механизм.
Восстанови ключевые механизмы юнита — log-based capture vs polling, slot как заряженное ружьё, snapshot-then-stream, захват delete и at-least-once доставку — не подглядывая в урок.
- 01Почему log-based CDC бьёт polling таблицы по курсору на каждой важной оси?
- 02Объясни, почему logical replication slot может уронить primary, и что ты ставишь перед запуском CDC.
- 03Что такое старт snapshot-then-stream и почему snapshot — опасная часть?
- 04Почему захват полных DELETE требует REPLICA IDENTITY FULL и сколько это стоит? Что такое tombstone?
- 05Почему доставка CDC по факту at-least-once, и как это меняет написание consumer? Как помогает порядок?
- 06Когда ты выберешь outbox-паттерн вместо прямого захвата доменных таблиц и как он соотносится с CDC?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: log-based CDC бьёт polling по задержке, полноте, query-нагрузке и вторжению в приложение; безусловное обещание slot по WAL — и почему CDC возобновляем, и почему может заполнить диск, поэтому ты алертишь и ставишь cap; старт — snapshot-then-stream, где incremental snapshot избегает долгого lock; полные delete стоят WAL через REPLICA IDENTITY FULL и требуют tombstone для compaction; доставка — at-least-once, поэтому consumers должны быть идемпотентны; а outbox композируется с CDC, давая атомарный, отвязанный от схемы контракт событий.