❗️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.

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

❗️System design — строим скелет будущей системы❗️

Уже имеем:
✅ Понятные и подтверждённые требования.

Задача этапа:
Построить каркас взаимодействия ключевых компонентов по «happy path» — идеальному сценарию работы системы.

Что нужно сделать:
1️⃣ Выделить ключевые сущности системы:
- Клиенты (фронты, мобильные приложения, внешние системы);
- Сервисы (микросервисы);
- Хранилища (базы данных).

2️⃣ Соединить их стрелками в рамках взаимодействия по "happy path". На стрелках ничего писать не нужно, все способы взаимодействия будем определять на следующих этапах.

Если пропустили первую часть, то она тут.

P.S. Окно вернул:)
P.S.S. Не ленимся записываться на выходные, группа по EDA пустая 😲

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

❗️REST API сегодня 16:00❗️

До начала занятия осталось несколько часов, еще можно успеть записаться :)

Описание программы:

Уровень: junior.
Требуемые навыки: Умение читать ER-диаграмму.
Кол-во участников: до 5.
Длительность: ~4 часа.
Программа:
✅ Форматы данных;
✅ HTTP-методы и их свойства;
✅ REST и RESTfull;
✅ Обработка ошибок в синхронных интеграциях.

Практика:
✅ Проектирование REST API для нового сервиса;
✅ Внедрение пагинации и фильтрации;
✅ Swagger;
✅ Postman.

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

❗️System design — проектируем интеграции❗️

Уже имеем:
✅ Понятные и подтверждённые требования;
✅ "Скелет" будущей системы.

Задача этапа:
Выбрать способы интеграции между элементами системы. На каждой стрелке нашего "скелета" указать технологию, с помощью которой будет реализовано взаимодействие.

Если у вас мало опыта в проектировании интеграций, ловите небольшой "универсальный" подход, который покроет большинство кейсов:

1️⃣ Frontend ↔️ Backend
🔸Для синхронного взаимодействия используйте REST API. Это самый распространённый и понятный способ.
🔸Для асинхронного взаимодействия выбирайте WebSocket или SSE. Ссылки на посты, что это за звери, прикрепил:)

2️⃣ Backend ↔️ Backend
🔸Для синхронных взаимодействий также подойдёт REST API, но если вы знакомы с такой технологией как gRPC, то лучше использовать её.
🔸Для асинхронных интеграций выбирайте брокер сообщений, который вам ближе. Также у меня был пост, в котором я рассказывал, как правильно выбрать брокер для проекта.

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

Предыдущие части:
Шаг 1: правильно понимаем условия задачи;
Шаг 2: строим скелет будущей системы.

P.S. До конца скидок осталось 8 часов :)

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

❗️System design — выбираем БД❗️

Уже имеем:
✅ Понятные и подтверждённые требования;
✅ "Скелет" будущей системы;
✅ Технологии интеграций между элементами.

Задача этапа:
Выбрать технологии баз данных, подходящих под задачи сервисов.

В том же формате: небольшой "универсальный" подход, который покроет большинство кейсов:

1️⃣ Хранение структурированных сущностей
Если вам необходимо хранить данные о сущности с конечным набором атрибутов, то выбирайте PostgreSQL.

2️⃣ Хранение неструктурированных сущностей
Если ваши сущности имеют динамический набор атрибутов, то также выбирайте PostgreSQL, но для хранения меняющегося набора атрибутов используйте JSONB формат.

3️⃣ Аналитика и отчетность
Для построения отчетов и агрегации метрик на больших объемах используйте Clickhouse или другие колоночные(столбчатые) СУБД, с которыми у вас больше опыта.

4️⃣ Кеширование
Если нужен быстрый кеш, то выбирайте Redis.
Для хранения сессий он тоже отлично подойдёт.

⚠️ Это надежная опора, а не истина в последней инстанции. Всегда смотрите на специфику задачи и свой опыт!

Предыдущие части:
Шаг 1: правильно понимаем условия задачи;
Шаг 2: строим скелет будущей системы;
Шаг 3: проектируем интеграции.

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

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

Уже имеем:
✅ Понятные и подтверждённые требования;
✅ "Скелет" будущей системы;
✅ Технологии интеграций между элементами;
✅ Технологии баз данных для сервисов.

Задача этапа:
Когда основа системы готова, пора добавить ключевые компоненты для масштабируемости и отказоустойчивости:

1️⃣ HTTP Proxy
Между FE и BE-сервисами с HTTP-интерфейсами добавляем HTTP Proxy.
Это необходимо для кеширования, балансировки нагрузки и безопасности.

2️⃣ Количество подов для сервисов
Всегда минимум 2 пода. Для сервисов с высокой нагрузкой увеличивайте количество подов или настраивайте HPA.

3️⃣ Количество партиций в топиках
Если вы используете Apache Kafka, то при увеличении числа подов сервисов не забывайте про количество партиций в топиках, которые эти сервисы читают. Ранее рассказывал, как правильно это сделать.

4️⃣ Кластерные базы данных
Если сервис участвует в ключевом бизнес-процессе вашей системы, то он обязательно должен иметь под собой кластерную базу данных для обеспечения отказоустойчивости и производительности. Ранее выходил цикл постов, в котором я подробно рассказывал про кластеризацию.

5️⃣ Общий взгляд на систему
Ещё раз посмотрите на то, что у вас получилось. Возможно, на каком-то из предыдущих этапах вы что-то не учли, и сейчас самое время это добавить.

Предыдущие части:
Шаг 1: правильно понимаем условия задачи;
Шаг 2: строим скелет будущей системы;
Шаг 3: проектируем интеграции;
Шаг 4: выбор технологий БД.

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