❗️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 опроса. Голосовать будем до вечера четверга, чтобы я успел скорректировать график интенсивов декабря и всех уведомить.

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

❗️Разбор задачки по System Design ❗️

Ссылка youtube

Эта задача досталась одному из подписчиков на собеседовании.

Условия задачи:

Разработка платформы для сети коворкинг-центров, объединяющей мобильное приложение для пользователей и веб-интерфейс для администраторов.

Для пользователей (мобильное приложение):
-Просмотр доступных рабочих мест;
-Выбор и бронирование места на определённое время;
-Интеграция с платежным шлюзом для оплаты бронирования (минимум 3 банка).

Для администраторов (веб-интерфейс):
-Управление каталогом рабочих мест (добавление, блокировка);
-Динамическое управление тарифами аренды;
-Просмотр агрегированной аналитики (Графики заполняемости пространства, Статистика посещаемости по времени и зонам).

Технические ограничения:
-Поддержка 1000+ одновременных пользователей;
-Формирование отчетов с задержкой не более 5 минут.

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

🆕 Оценка навыков 2.0 🆕

Как и обещал, новая оценка навыков уже доступна!

Что изменилось во второй версии:
✅ Только практические задания из реальных собеседований;
✅ Самые актуальные темы под текущие требования рынка;
✅ Время на решение не ограничено;
✅ Система сертификации для вашего резюме.

Также как и ранее я самостоятельно проверяю ваше решение и направляю подробный разбор.

Те, кто наберёт 80 баллов из 100, получат сертификат, который можно прикрепить к резюме. Полностью честный, валидируется по ссылке или QR-коду.

Кейсы, которые вас ждут:
🔸System Design;
🔸BPMN/UML;
🔸Проектирование синхронных и асинхронных интеграций;
🔸Работа с событиями;
🔸Проектирование структуры БД;
🔸SQL.

Вторая версия стала платной, потому что теперь это не просто проверка теоретических знаний, а полноценный аудит ваших хардскиллов с сертификатом для резюме.

Чтобы попробовать свои силы, жмите сюда 👈

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

❗️Вебинару быть в субботу 06.12❗️

По итогам опроса побеждает 6 декабря :)

Теперь выбираем время, опрос также ниже 👇

Технические неполадки, не поставил галочку с выбором нескольких ответов, нужно переголосовать:)

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

❗️Вебинар пройдет 06.12 в 13:00❗️

По итогам опроса, с небольшим отрывом, побеждает 13:00.

Итог: встречаемся с вами в субботу 06.12 в 13:00 по МСК.

Ссылка на подключение будет накануне :)

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

❗️Ещё одна задачка по System Design ❗️

В этот раз разобрал задачку с собеседования на позицию senior в финтех.

Разбор получился почти на 40 минут и 2.5гига🙃, поэтому вот ссылка на youtube.

❓Условие задачи:
Банк запускает новый продукт для сбора обратной связи от клиентов. Необходимо внедрить в мобильное приложение и интернет-банк новый сервис «Умный Опрос».

Описание сервиса:
- После определенных действий (например, покупки ценных бумаг, оформление кредита) клиенту показывается короткий опрос (3-5 вопросов).
- Ответы сохраняются в сыром виде, затем агрегируются и показываются в виде дашбордов менеджерам по продукту.
- Сервис состоит из:
1. REST API (принимает ответы).
2. Админ-панель (для настройки опросов и просмотра дашбордов).
3. База данных (опросы, ответы).

Что нужно сделать:
1. Проектирование интеграции:
Описать, как новый сервис будет взаимодействовать с существующими системами (мобильное приложение, интернет банк, сервисы других продуктов, API gateway, система нотификаций).

*Текущие сервисы работают по событийной модели.

2. Расчет мощностей (Sizing):
На основе вводных данных произвести расчет:
- Количество пользователей: 20 млн активных клиентов в месяц.
- Ожидаемое количество опросов: 1% от пользователей в день.
- Размер одного опроса: ~20 КБ.
- Дашборды: Одновременно до 100 менеджеров могут работать с системой в час пик.

Рассчитать:
- Количество подов внедряемых сервисов.
- Требования к CPU/RAM для каждого сервиса.
- Объем хранилища и требования к производительности для базы данных.
- Оценочный сетевой трафик.

P.S. На youtube канал подписываться не прошу, использую его как техническую платформу, но если подпишитесь, мне будет приятно:)

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