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

Это самый простой и распространенный способ начать использовать 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;
🔸Комбинированный подход;
🔸Шардирование;
🔸Партиционирование.

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

❗️System design — правильно понимаем условия задачи❗️

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

1️⃣ Терминология:
Одни и те же понятия в разных компаниях могут трактоваться по-разному. Если какой-то термин кажется вам размытым или незнакомым — не стесняйтесь задать уточняющий вопрос. Лучше переспросить, чем строить систему на неверных предположениях.

2️⃣ Масштаб системы:
Обязательно уточняйте количество пользователей в системе, и сколько операций производят эти пользователи с учетом пиковых нагрузок. Если присутствуют внешние вызовы от других систем, также уточняйте их количество в промежуток времени. Также не забывайте про объемы данных при хранении и передаче.

3️⃣ Нефункциональные требования:
Многие специально "упускают" их при постановке задачи, чтобы проверить, спросите вы о них или нет. Поэтому смело уточняйте требования к безопасности, производительности, доступности, масштабируемости и т.д.

❗️Самое главное:
Записав все требования, обязательно проговорите вслух, какую задачу вы собираетесь решать. Это позволит интервьюеру подтвердить ваше видение или вовремя внести коррективы.

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

❗️Остаток мест в группах❗️

🟢 08.11 REST API — 4 места, записаться;
🟢 09.11 Event-Driven Architecture — 5 мест, записаться;
🔴 22.11 Функциональные требования — 1 место, записаться;
🟡 23.11 Нотация С4 — 2 места, записаться;
🟢 29.11 Нотация С4 — 4 места, записаться.

Подробная информация о программах:
✅REST API;
✅Event-Driven Architecture;
✅Функциональные требования;
✅Нотация С4.

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