🆕 Новая тема интенсива: Event-Driven Architecture 🆕

Уровень: Middle+.
Требуемые навыки: Понимание принципов работы распределённых систем, Apache Kafka.
Кол-во участников: до 4.
Длительность: ~4 часа.
Программа:
✅ Немного общей теории по распределенным системам;
✅ Что такое "событие";
✅ Что такое EDA;
✅ Сильные и слабые стороны EDA;
✅ Модели данных для EDA;
✅ Мониторинг в EDA.

Практика:
✅ Проектируем EDA систему с нуля;
✅ Готовим схему расположения сервисов;
✅ Расширяем функционал системы с использованием имеющихся событий;
✅ Внедряем в систему мониторинг.

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

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

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

❗️График октября немного нестандартный, ввиду загрузки на проекте, пока не смогу проводить занятия по понедельникам. Поэтому смещаемся на субботу 16:00 🫡

Брокеры сообщений:
🔸Суббота 04.10 16:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

Функциональные требования:
🔸Воскресенье 05.10 12:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

🆕Event-Driven Architecture:
🔸Суббота 25.10 16:00
🔸Воскресенье 26.10 12:00
👤Количество мест: 4
ℹ️ Описание интенсива
👉 Запись

⚙️ Подробный разбор этапов: Расчет партиций для топиков.

Входящие параметры:
2 топика: raw-events и enriched-events.
2 консьюмера: сервис стримингого обогащения и Elasticserch sink connector.

Расчеты:
Cервис стримингого обогащения имеет 6 подов по умолчанию и HPA 6-12.

ℹ️Вспоминаем правило:
Один под может читать несколько партиций, но несколько подов не могут читать одну партицию.

Для успешного распределения нагрузки при срабатывании HPA, нам необходимо сделать минимум 12 партиций.
Пока подов 6, каждый из них будет читать по 2 партиции, но после срабатывания HPA произойдёт ребалансировка, и каждый под будет читать по 1 партиции.

Elasticserch sink connector всегда работает в 3-х подах. Поэтому для второго топика достаточно 3 партиций для балансировки нагрузки.

Итог:
✅ raw-events — 12 партиций;
✅ enriched-events — 3 партиции.

Ссылка на кейс 👈
Ссылка на общее решение 👈

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

❗️Итоговый пост по кейсу с полнотекстовым поиском❗️

Как видите, кейс оказался не таким сложным, как выглядел на первый взгляд:)

⚙️Описание самого кейса
✅Верхнеуровневое решение
Этапы:
1️⃣Сервис стримингого обогащения
2️⃣Мощности для Apache Kafka
3️⃣Elasticsearch sink connector
4️⃣Расчет партиций для топиков
5️⃣Кластер Elasticsearch

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

❗️Предложение по занятию в эту субботу:

В группе на 04.10 16:00 "Брокеры сообщений" пока нет записей (хотя за них проголосовали 42 человека 🙃), скорее всего это связано с нестандартным графиком.

Было много запросов по другим темам, поэтому предлагаю сделать замену, если соберутся желающие поучиться :)

Ниже прикреплю опрос, голосуйте за интересующую тему только, если сможете посетить занятие :) 👇

🏁По итогам голосования оставляем на завтра "Брокеры сообщений" :)

Запись снова доступна 👈

❓ Немного о 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️⃣ Каждый мастер имеет собственный набор слейв-узлов, которые реплицируют данные только со своего мастера.

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

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

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