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

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

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: выбор технологий БД.

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

❗️Места на интенсивах❗️

Ещё остались места в группах на этих выходных:
🔴 22.11 Функциональные требования — 1 место, записаться;
🟡 23.11 Нотация С4 — 2 места, записаться.

Также будет одно занятие через неделю:
🟢 29.11 Нотация С4 — 4 места, записаться.

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

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

❗️System design — мониторинг❗️

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

Задача этапа:
Внедрить мониторинг системы.

Если имеете опыт использования каких-то решений для мониторинга, смело применяйте его. Если опыта у вас нет, то ещё один "универсальный" список технологий:

1️⃣ Prometheus
Система сбора и хранения метрик. Собирает данные о работе системы (CPU, память, количество запросов, ошибок) и хранит их во временной базе данных.

2️⃣ Grafana
Визуализация метрик. Берет данные из Prometheus и показывает их в виде красивых дашбордов с графиками, таблицами и индикаторами.

3️⃣ Alertmanager
Управление оповещениями. Принимает алерты от Prometheus, группирует их, убирает дубли и отправляет уведомления в нужные каналы (Email, Slack, Telegram и тд).

4️⃣ Jaeger
Трассировка распределенных систем. Показывает полный путь одного запроса через все микросервисы, где и сколько времени он выполнялся, что помогает находить узкие места.

5️⃣ ELK (Elasticsearch, Logstash, Kibana)
Сбор и анализ логов:
- Elasticsearch — поисковый движок для хранения и поиска по логам;
- Logstash — сбор, парсинг и преобразование логов;
- Kibana — веб-интерфейс для просмотра и анализа логов.

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

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

1️⃣0️⃣0️⃣0️⃣

Набрали первую тысячу подписчиков канала 🎉

Ловите 2 анонса в честь этого события:

1️⃣ Проведем первый вебинар.
Тему сообщу в отдельном посте, а с датой и временем определимся через голосование.

2️⃣ Оценка навыков v2.
Готовлю к запуску новую версию, которая будет целиком основана на решении практических задач. Запуск уже на следующей неделе.

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

❗️Итоговый пост: теория по System Design❗️

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

На следующей неделе начну разбирать практические примеры решения задач, которые вы приносили с собеседований 🫡

Разборы сделаю в формате длинных видео с записью экрана, поэтому выходить будут немного реже :)

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

❗️Обновление интенсива по C4❗️

В тайминг практической части смог уместить работу со structurizr.

Structurizr — нативная утилита для визуализации архитектуры на основе нотации C4. Работает по принципу Diagrams as Code.

В группе на воскресенье 12:00 МСК осталось всего 1 место, записывайтесь тут:)

P.S. Также 1 место осталось на занятие по функциональным требованиям завтра в 16:00 МСК, записаться можно тут.

❗️Первые подробности по вебинару❗️

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

Поэтому тема: "Распределенные системы".

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

Теперь к организационному:
✅ Участие бесплатное;
🎤 50-60 минут на презентацию;
❓ 20-30 минут ответы на ваши вопросы.

⏰Но нам нужно определиться с датой и временем.

Ниже прикреплю 2 опроса. Голосовать будем до вечера четверга, чтобы я успел скорректировать график интенсивов декабря и всех уведомить.

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