❓ Немного о CQRS простыми словами

CQRS (Command Query Responsibility Segregation) — это архитектурный паттерн, который предполагает разделение ответственности для операций чтения и записи данных.

Command (Команда) — изменить данные (создание, обновление, удаление);
Query (Запрос) — получить данные (чтение);

🔽Command-сторона — это ваш основной сервис, который обрабатывает действия, меняющие состояние.

🔼Query-сторона — это специально построенная система отчетов или кэш, которая моментально отдает данные, но сама их не меняет. Модель данных для чтения оптимизирована для быстрых и сложных запросов — она может быть денормализованной, чтобы минимизировать количество JOIN.

P.S. Примером применения подхода является наш кейс про полнотекстовый поиск.

Системный анализ | Дмитрий Помаскин

❗️Остаток мест на интенсивах❗️

Первая половина занятий октября прошла 👍

Осталось 2 занятия по новой теме Event-Driven Architecture:

🟡 Суббота 25.10 16:00 — осталось 1 место;
🟢 Воскресенье 26.10 12:00 — осталось 4 места.

ℹ️ Описание программы
👉 Запись

Системный анализ | Дмитрий Помаскин

❓ Разделение чтения и записи: Event Sourcing

Наиболее мощный и сложный способ разделения чтения и записи.

Основная идея:
Состояние системы не хранится, а восстанавливается из последовательности событий (Event Sourcing). Команды генерируют события, которые затем обрабатываются "проекциями" для обновления хранилищ чтения.

Как работает:
1️⃣ Command Side: При получении команды создается событие и сохраняется в журнале событий (Event Store).

2️⃣ Event Store (Журнал событий): Это единственный источник истины. Хранит неизменяемую последовательность событий.

3️⃣ Projections (Проекции): Это фоновые процессы, которые слушают события из Event Store. Их задача — обновлять хранилища для чтения на основе этих событий.

4️⃣ Query Side: Запросы выполняются из оптимизированных хранилищ, которые были заполнены проекциями.

P.S. Кто пропустил пост про CQRS, он тут.

Системный анализ | Дмитрий Помаскин

❓ Разделение чтения и записи: на уровне одной базы данных

Это самый простой и распространенный способ начать использовать CQRS. Он не требует сложной инфраструктуры.

Основная идея:
Используется одна и та же база данных, но для операций Чтения (Query) и Записи (Command) создаются отдельные модели.

Как работает:
1️⃣ Команды (Commands): используют одну схему объектов (ORM-модели, сущности) для изменения данных.

2️⃣ Запросы (Queries): используют другие, упрощенные модели (например, View Models), которые могут быть оптимизированы для конкретных запросов. Запросы могут обращаться к тем же таблицам, но избегают сложных связей, используя, например, SELECT только нужных полей.

➕Согласованность: Данные для чтения всегда актуальны.
➖Производительность: Нагрузка на чтение и запись ложится на один сервер БД.

P.S. Кто пропустил пост про CQRS, он тут.

Системный анализ | Дмитрий Помаскин

❓ Разделение чтения и записи: использование репликации.

Это модифицированный вариант предыдущего способа — переходим на кластер.

Основная идея:
Настраивается репликация с основной базы данных (мастера) на одну или несколько подчиненных реплик. Команды пишутся в мастер, а запросы читаются из реплик.

Как работает:
1️⃣ Поднимается кластер БД с иерархией master-slave.

2️⃣ Операции на запись приходят в master.

3️⃣ Данные реплицируются в slave.

4️⃣ Операции на чтение приходят в реплику(slave).

➕Масштабируемость чтения: Нагрузка на чтение распределяется по репликам.
➕Производительность: Уменьшается нагрузка на основную базу данных.
➖Возможная несогласованность: Данные на репликах могут немного отставать от мастера (задержка репликации).

P.S. Кто пропустил пост про CQRS, он тут.

Системный анализ | Дмитрий Помаскин

❗️Итоги по разделению чтения и записи❗️

Все посты:
🔸CQRS простыми словами
🔸Single DB
🔸Read Replica
🔸Separate Read DB
🔸Event Sourcing

Как выбрать?
1️⃣ Начните с первого способа. Если у вас монолит и вы хотите улучшить структуру кода, начните с разделения моделей в одной БД.

2️⃣ Переходите ко второму, если у вас высокие нагрузки на чтение, и вы готовы смириться с небольшой задержкой репликации.

3️⃣ Рассмотрите третий, когда у вас есть конкретные, очень медленные запросы, которые можно ускорить с помощью денормализации или другой СУБД.

4️⃣ Используйте четвертый (Event Sourcing) для сложных предметных областей с высокими требованиями к аудиту, масштабируемости и гибкости, и только если ваша команда готова к его сложности.

Главный принцип — не усложнять без необходимости. Часто первых двух способов бывает более чем достаточно для решения большинства практических задач.

Системный анализ | Дмитрий Помаскин

❗️Event-Driven Architecture❗️

Осталось 2 занятия по новой теме:

🟡 Суббота 25.10 16:00 — осталось 1 место;
🟢 Воскресенье 26.10 12:00 — осталось 3 места.

ℹ️ Описание программы
👉 Запись

Системный анализ | Дмитрий Помаскин

❗️Новый цикл видео: кластерные БД❗️

Начнем с базовых определений:

✅ Standalone — это классическая "одиночная" база. Один сервер, который делает всё: принимает запросы, хранит данные, отвечает за них.

✅ Cluster — это несколько серверов, которые притворяются одной базой данных, при этом состояние данных на этих серверах может обновляться не в один и тот же момент времени, а разные узлы могут отвечать за разные задачи.

Системный анализ | Дмитрий Помаскин

❗️Master-Slave репликация: простыми словами❗️

Принцип: один главный сервер принимает изменения, а его копии раздают данные для чтения.

Как работает?
1️⃣ Запись (Write) — ТОЛЬКО в мастер. Все INSERT/UPDATE/DDELETE идут сюда.
2️⃣ Синхронизация — мастер записывает изменения в лог.
3️⃣ Копирование — слейвы постоянно читают лог и обновляют свои данные.
4️⃣ Чтение (Read) — можно делать с любого узла: мастера или слейвов.

Зачем это нужно?
✅ Распределение нагрузки — чаще всего чтение реализуют со слейвов, чтобы распределить нагрузку.
✅ Масштабирование чтения — добавление новых слейвов увеличит пропускную способность для запросов на чтение.
✅ Резервное копирование — бэкапы делаем со слейвов, не нагружая мастер.

⚠️ Важный нюанс: Replication Lag
Записали данные в мастер → сразу прочитали со слейва → получили старые данные!
Это нормально — между узлами всегда есть небольшая задержка репликации.

P.S. Для чувствительных данных запросы на чтение можно отправлять в мастер, чтобы избежать неконсистентности.

Системный анализ | Дмитрий Помаскин

🗓 График ноября 🗓

Составляю программу практических интенсивов на ноябрь.

Всё как обычно — голосуем за темы, которые хотели бы видеть в расписании😉

Описание программ:
🔸Проектирование REST API;
🔸Базы данных;
🔸Функциональные требования;
🔸Брокеры сообщений;
🔸Event-Driven Architecture (в группах на эти выходные осталось немного мест).

Опрос ниже 👇

P.S. Новая тема ноября — нотация С4, подробности немного позже:)

Системный анализ | Дмитрий Помаскин

❗️Master-Master (Multi-Master)❗️

Принцип: это архитектура кластера, где несколько серверов (нод) являются главными.

Как работает?
1️⃣ Каждый узел может принимать запросы на запись — нет единой точки отказа для операций изменения данных.
2️⃣ Изменения, сделанные на одном мастере, реплицируются на все остальные — система стремится к согласованности данных.

Зачем это нужно?
✅ Разные узлы могут отвечать на запросы из разных регионов — снижая задержку для пользователей.
✅ Повышенная доступность — выход из строя одного мастера не останавливает запись в систему.

⚠️ Важный нюанс: конфликты репликации.
Если два мастера одновременно изменят одни и те же данные, системе потребуется их разрешить.

Системный анализ | Дмитрий Помаскин

❗️Multi-Master + Master-Slave❗️

Принцип: архитектура, которая объединяет преимущества Master-Master и Master-Slave подходов.

Как работает?
1️⃣ Несколько мастер-узлов работают в режиме Master-Master между собой, обеспечивая отказоустойчивость для операций записи.
2️⃣ Каждый мастер имеет собственный набор слейв-узлов, которые реплицируют данные только со своего мастера.

Зачем это нужно?
✅ Многоуровневая отказоустойчивость:
- Если падает один мастер — слейв из его узла занимает его место.
- Если падает слейв — его мастер и другие слейвы продолжают работать.
- Если падает узел — система продолжает работать на другом узле.
✅ Гибкое распределение нагрузки:
- Запись распределяется между мастерами.
- Чтение масштабируется практически бесконечно за счет слейвов каждого мастера.
- Географическое распределение: Пользователи из Европы читают со слейвов европейского мастера, из Азии — с азиатских слейвов.

Недостатки подхода:
⚠️Высокая стоимость инфраструктуры;
⚠️Сложность управления и настройки;
⚠️Каскадные сбои — проблемы на мастере могут отразиться на всех его слейвах;
⚠️Задержки репликации на нескольких уровнях.

Системный анализ | Дмитрий Помаскин

❓Что такое шардирование в БД?

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

ℹ️ Шардирование — это метод распределения данных в базе данных между несколькими серверами (шардами) для повышения производительности и масштабируемости системы.

Основные типы шардирования:
✅ Горизонтальное шардирование — данные разделяются по диапазону значений (аналогично партиционированию);
✅ Вертикальное шардирование — разные таблицы или столбцы в них размещаются на разных серверах;
✅ Хэш-шардирование — используется хэш-функция от ключа шардирования для определения места хранения.

⚠️Отличие шардирования от классического кластера — при шардировании данные не реплицируются, а просто распределяются по шардам. В кластере данные реплицируются между нодами.

Системный анализ | Дмитрий Помаскин

❗️Остаток слотов на выходные❗️

Event-Driven Architecture

🟡 Суббота 25.10 16:00 — осталось 1 место;
🟡 Воскресенье 26.10 12:00 — осталось 2 места.

ℹ️ Описание программы
👉 Запись

Системный анализ | Дмитрий Помаскин

❓Что такое партиционирование в БД?

Раз заговорили про шардирование, то повторим и партиционирование :)

ℹ️ Партиционирование — это метод разделения больших таблиц в базе данных на меньшие, более управляемые части для повышения производительности и упрощения работы с данными.

Основные типы партиционирования:
✅ По диапазону - данные разделяются по диапазону значений (например, по датам);
✅ По значениям - разделение по конкретным значениям атрибутов (например, по регионам);
✅ По хэшу - равномерное распределение по партициям с помощью хэш-функции.

Системный анализ | Дмитрий Помаскин

🆕 Новая тема интенсива: С4 🆕

Уровень: Middle.
Требуемые навыки: Понимание принципов работы распределённых систем.
Кол-во участников: до 4.
Длительность: ~3.5 часа.
Программа:
✅ Что такое нотация С4;
✅ Для чего она нужна;
✅ Какие уровни бывают;
✅ Основные элементы всех уровней;
✅ Что из этого реально стоит использовать в работе;
✅ Какие инструменты существуют для работы с С4.

Практика:
✅ Подготовим описание системы на разных уровнях;
✅ Модифицируем схему по результатам доработок;
✅ Работа со structurizr.

P.S. Запись будет открыта завтра (29.10) в 16:00 по МСК вместе с общим расписанием ноября.

Системный анализ | Дмитрий Помаскин

‼️Запись на интенсивы ноября открыта‼️

Время указано по МСК:

REST API:
🗓Суббота 08.11 16:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

Event-Driven Architecture:
🗓Воскресенье 09.11 12:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

Функциональные требования:
🗓Суббота 22.11 16:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

🆕Нотация С4:
🗓Воскресенье 23.11 12:00
🗓Суббота 29.11 16:00
👤Количество мест: 4
ℹ️ Описание интенсива
👉 Запись

❗️System design — анонс нового цикла видео❗️

❓Что это такое?
System Design — это процесс создания высокоуровневого описания системы, которое, отталкиваясь от требований, отвечает на вопрос как она будет реализована с точки зрения архитектуры.

Также это неотъемлемая часть работы системного аналитика и важный этап интервью при поиске работы.

❓Что будем разбирать?
После небольшой теоретической части разберем реальные задачи, которые ребята приносили на онлайн-консультации или после прохождения курсов.

❗️Приносите свои кейсы
Если у вас есть интересные задачки на проектирование, которые вам давали на собеседованиях, присылайте их мне в ЛС или пишите в комментариях к этому посту, я разберу их решение в видеоформате.

P.S. В группе по функциональным требованиям 22.11 осталось 1 место, если планировали посетить, не откладывайте:)

Системный анализ | Дмитрий Помаскин

Итоги октября 🎉

Надеюсь, до конца года разменяем первую сотню💪

Искренне радует, что, закончив один курс, люди возвращаются за вторым, а ещё есть те, кто посетил вообще ВСЕ интенсивы🫡

❗️Итоговый пост по кластерным БД❗️

Пока готовлю материалы по system design, вот все посты по кластерным БД:

🔸Общая терминология;
🔸Master-slave;
🔸Multi-master;
🔸Комбинированный подход;
🔸Шардирование;
🔸Партиционирование.

Системный анализ | Дмитрий Помаскин