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

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

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

Описание программ:
🔸Проектирование 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.

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

❗️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 часов :)

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