System Design World

💻 CDC через Transaction Log Tailing

✍️ В прошлом посте мы обсудили CDC и outbox pattern.

Напомню идею:
CDC (Change Data Capture) - механизм, который позволяет отследить изменения в базе данных и передать их в другую систему.

🎟 В нашем booking-примере:
➡️ Postgres - source of truth.
➡️ ElasticSearch - read model для быстрого поиска.
➡️ CDC - способ доставить изменения из Postgres в ElasticSearch.

🤎 Идея реализации CDC с помощью Transaction Log Tailing
База данных уже фиксирует все изменения в своём transaction log.
В Postgres такой лог называется Write-Ahead Log (WAL).

Когда мы меняем данные в таблице rooms, Postgres записывает это изменение в WAL.

⚠️ Например:
➡️ Обновили цену номера в таблице rooms.
➡️ Postgres записал изменение в WAL.

🫴 Далее мы хотим забирать такие изменения:
➡️ Специальный CDC-инструмент читает WAL.
➡️ Превращает изменение в событие.
➡️ Пересылает в ElasticSearch, Kafka или другую систему.
Получаем классическую схему в подобных System Design задачах:

Postgres -> WAL -> CDC Connector -> ElasticSearch

В этом подходе наше основное приложение не создаёт специальное событие(что оно делало в подходе с outbox).

🎖 Почему это удобно?
➡️ Нет изменений в коде приложения.
➡️ Можно отслеживать изменения автоматически.

Однако, не забываем и про минус такой реализации:

Transaction log хранит не бизнес-события, а технические изменения в базе.

У нас будет сухое описание:
➡️ не "RoomPriceChanged",
➡️ а "в таблице rooms у строки room_id = 42 изменилось поле price".

❓ Какие ещё заметили минусы?
И важный плюс по сравнению с outbox паттерном? 🐤

🔥 Итог:
Transaction log tailing - это способ реализации CDC, при котором мы автоматически читаем изменения напрямую из transaction log базы данных.

Если прошлый неожиданный пост у которого сразу пошли лайки наберёт 20 реакций - я чего-то не понимаю в подаче контента 😅

Р

🔥 Дух Анкориджа. А если бы...

Калининград. Научно исследовательское судно "Витязь".

Зашли в историческую экспозицию.
Сделал несколько наблюдений:
1) Продажу Аляски воспринимаю как личную трагедию
2) И 150 лет назад были компании, мануфактуры, акции, войны, государственные дела

Интересно, если бы Аляска осталась у Империи, как бы сложилась история?...

💻 3D System Design. Запись

🎮 В игровом стиле прошлись по базе System Design.

🔘Взяли задачу - проектирование маркетплейса.
🔘Обсудили контекст.
🔘И пошли в симулятор 🎮

💡 К примеру, выкручиваем больше write трафика - больше клиентов делают заказы.
Больше search - полнотекстовый поиск.

Последовательно проектируем систему и обсуждаем популярные System Design Паттерны.

👀 Смотреть здесь - youtube.

3D System Design с Yet Another Analyst ☺️

Upd. Лампово посидели, спроектировали маркетплейс в симуляторе. Запись будет у Андрея.
Картинки с вебинара в комментариях👌

💻 System Design: что такое CDC

В прошлом посте мы разобрали CQRS на примере booking-сервиса.

У нас была схема:
🫰 Админ обновляет данные номера в Postgres.
🔍 Пользователь ищет номера через ElasticSearch.

Между ними есть важная часть:
Postgres -> CDC -> ElasticSearch

CDC - Change Data Capture.
Перевожу для себя так - Захват Изменяющихся Данных
Если просто - CDC позволяет отследить изменения в базе данных и передать их дальше в другую систему.

CDC отвечает на вопрос:
«Как изменения из source of truth доезжают до read model?»

В нашем примере:
Postgres - source of truth.
ElasticSearch - read model для быстрого поиска.
CDC - механизм доставки изменений между ними.

❓ Как реализовать эту концепцию?
Один из способов реализовать CDC - outbox pattern.

Идея:
Когда сервис обновляет данные в Postgres, он в той же транзакции записывает событие в отдельную таблицу, называемую outbox.

Например:
➡️ Обновили цену номера в таблице rooms.
➡️ В этой же транзакции записали событие room_price_updated в таблицу outbox_events.
➡️ Отдельный worker читает outbox_events.
➡️ Worker отправляет изменение дальше.

Почему это удобно?
➡️ Потому что изменение данных и запись события происходят атомарно.

Мы избежим ситуации, когда:
➡️ Данные в Postgres обновились.
➡️ А событие для ElasticSearch потерялось.

👍 Плюсы outbox pattern:
🤎 Надёжность: данные и событие записываются в одной транзакции.
🤎 Можно контролировать формат события.
🤎 Хорошо подходит для бизнес-событий: RoomUpdated, PriceChanged, BookingCreated.
🤎 Можно добавить retry, статус обработки и dead letter queue.

Минусы:
Давайте опишем в комментариях 👍

Итог:
CDC - это способ доставить изменения из source of truth в другие системы.
А outbox pattern - это один из практичных способов сделать такую доставку надёжнее.
Цена - больше инфраструктурной логики и больше ответственности за обработку событий.

Больше про паттерн:
🔘50 оттенков Transactional Outbox - Денис Цветцих
🔘Transaction Outbox под нагрузкой: как не потерять ни одного события при 100k+ RPS - Олег Мифле
🔘Outbox pattern для System Design Интервью - моя статья

3D System Design с Yet Another Analyst ☺️

А что если количество запросов вырастет в 10 000 раз?

- популярный вопрос в конце System Design Интервью.

А давайте проверим! 😊

🔥 С Андреем Бураковым из Yet Another Analyst спроектируем систему и дадим жаркой нагрузки!👨‍💻

Когда?
Во вторник(14.07.26) в 19:00

Где?
По ссылке на канале. Будет ближе к старту ☑️

💻 System Design: CQRS на примере booking-сервиса

Допустим, мы проектируем сервис бронирования номеров.

Кейс:
🔘Админ обновляет информацию о номере в Postgres
🔘Пользователь ищет номера через ElasticSearch

🎯 Получаем следующую схему:
Postgres является source of truth.
Храним основную информацию: номер, отель, цену, описание, доступность.

ElasticSearch в нашей кейс - это read model.
Нужен для быстрого поиска: фильтры по городу, датам, цене, удобствам, рейтингу и текстовому описанию.

Таким образом получаем CQRS-схему:
Запись идёт в одну модель
Чтение из другой.

Но в архитектуре не бывает идеального решения.
Чем жертвуем здесь?

🟢Админ может поменять цену в Postgres, а пользователь ещё несколько секунд будет видеть старую цену в поиске.
🟢Или номер уже стал недоступен, но всё ещё отображается в выдаче.

Потому что данные в ElasticSearch обновляются не мгновенно.

И всё это из-за replication lag.

💡 Поэтому в такой архитектуре важно заранее решить:

➡️ какие данные можно показывать с задержкой;
➡️ какой лаг допустим для бизнеса: 1 секунда, 10 секунд, минута;
➡️ что делать, если пользователь выбрал номер из устаревшей выдачи;
➡️ нужно ли перед бронированием перечитывать актуальные данные из Postgres;
➡️ как мониторить задержку между Postgres и ElasticSearch;
➡️ как объяснять пользователю, что цена или доступность могли измениться.

✍️ Workaround
Использовать ElasticSearch для поиска, но перед финальным бронированием всегда проверять актуальную цену и доступность в Postgres.

То есть ElasticSearch отвечает на вопрос:
«Что примерно подходит под запрос пользователя?»

А Postgres отвечает на вопрос:
«Можно ли это действительно забронировать прямо сейчас?»

2️⃣ Таким образом мы решили две задачи:
1) Улучшаем user experience - пользователь может искать номера по разным параметрам и текстовым запросам
2) Перед бронированием показываем финально актуальные данные.

Итог
CQRS (Command Query Responsibility Segregation) позволяет разделить обновление и чтение данных, чтобы эффективнее реализовывать разные сценарии работы системы.

А что получает бизнес?
=> Быстрый сервис.
=> Удобный поиск.
=> Корректное бронирование.
=> Довольные пользователи.
=> profit 🚀

💪 Бодро начинаем неделю!

Посылаю заряд хорошего настроения и продуктивного состояния 🔥

😍 Saint TeamLeadConf 2026

После HighLoad++ пришло время моей архитектурной каты на TeamLeadConf - той самой конференции, видео с которой засматривал до дыр в бытность тим/тех лида в Сбере.
Пользуясь возможностью личного присутствия, в этот раз ходил на воркшопы.

➡️ "Черная Риторика" на работе.
Встречали такую?
🔘 В этом воркшопе разбились по группам для отработки сценариев. Нам досталась история технаря, который хочет уделить время рефакторингу, а менеджеру нужны новые фичи!
🔘 Фразы из такой риторики лились как из рога изобилия. Нужно было их находить и относись к категориям, а потом самим разыгрывать сценки.

Как парировать?

Сначала нужно осознать, что коллега сказал дичь пошёл не туда. Затем возвращаться в исходное русло обсуждения проблемы.

👨‍🎓 Под конец я был в роли обороняющегося - с командой, которую менеджер хочет вывести из удалёнки, потому что сейчас такой тренд в компании.
Я парировал тем, что

У нас интроверты, топ-перформеры и мы делаем нужные бизнесу крутые фичи лучше других 🤩

Время и аргументы против моей позиции кончились. Команда осталась на удалёнке 🕯

🚀 Свет, камера, мотор!
Популярность воркшопов зашкаливала. Под кату на всякий случай сделал больше задач, поставили больше столов. И правильно сделали!
Казалось бы, менеджерская конференция, а архитектурная ката зашла на ура)

Посетили в том числе мои знакомые:
🔘Иван Садовой - Техлид бизнес-юнита Авиа в Туту
🔘Александр Межов - ИТ-архитектор.
Повезло с моим куратором - архитектором Русланом Сафиным. Он же был соведущим и вторым судьёй.

Если хотите провести кату в своей компании, пишите! Опыт есть! ☺️

💡 Были ещё интересные доклады
В том числе организационные про AI. Думаю сделать встречу, чтобы поделиться текущими трендами и тем, что взял для себя.

Семейные гуляния
Мы оказались в Санкт-Петербурге на праздник "Алые Паруса"! 🔤
Были в Казанском Соборе, на перекрытом Невском(так необычно!), Спасе на Крови(наконец-то!).
А после из гостиницы даже увидели праздничный фейерверк. Питер в этот раз попал в ❤️