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

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

Базы данных:
🔸Понедельник 01.09 19:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

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

Брокеры сообщений:
🔸Понедельник 08.09 19:00
🔸Воскресенье 21.09 12:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

Проектирование REST API:
🔸Понедельник 15.09 19:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

⚙️ Практическое применение: SSE.

Три возможных применения технологии:
1️⃣ Уведомления — система отправляет вам уведомление о наступлении нового события. Например, получение письма на почту.
2️⃣ Системы мониторинга — одна система постоянно отправляет метрики в другую систему, которая занимается агрегацией показателей.
3️⃣ Лента новостей — система отправляет события, которые видят все пользователи на клиенте. Например, текстовая трансляция футбольного матча.

P.S. Кто пропустил теоретическую часть, жмём сюда.

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

🗓 Завтра 20.08 в 18:00 по МСК будет открыта запись на практические интенсивы сентября 🗓

По результатам нашего опроса в программу сентября включил:

🔄 Брокеры сообщений — 2 интенсива;
🔄 Проектирование REST API — 1 интенсив;
🔄 Базы данных — 1 интенсив;
🆕 Функциональные требования — 2 интенсива.

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

🆕 Функциональные требования — новая тема практического интенсива 🆕

Будем учиться писать ФТ так, чтобы у разработчиков не осталось вопросов :)

Подробнее:
Тема: Функциональные требования.
Уровень: junior.
Требуемые навыки: Работа с ER-диаграммой, понимание принципов работы REST API.
Кол-во участников: до 4.
Программа:
✅ Виды требований;
✅ Какие бывают ограничения и как они влияют на ФТ;
✅ Что включать в ФТ;
✅ Правильная структура ФТ;
✅ Где описывать ФТ.

Практика:
Подготовка ФТ под различные кейсы:
✅ FRONT;
✅ BACK;
✅ Интеграции(синхронные и асинхронные);
✅ Базы данных.

Запись будет открыта одновременно со всеми интенсивами сентября.

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

⚙️ Практическое применение: web-socket.

Пять, на мой субъективный взгляд, популярных применений технологии:

1️⃣ Онлайн-чаты — вы отправляете сообщения на сервер, сервер передает новые сообщения вам.
2️⃣ Онлайн-игры — ваши действия передаются на сервер, действия других игроков приходят к вам на клиент.
3️⃣ Финансовые биржи — обновление котировок в реальном времени с минимальной задержкой.
4️⃣ Совместная работа — изменения, внесённые разными пользователями, синхронизируются без перезагрузки.
5️⃣ Удалённое управление умным домом — получение данных с устройств и передача команд на устройства. Речь о взаимодействии с пользователем через браузер или приложение.

P.S. Кто пропустил теоретическую часть, жмём сюда.

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

❓И ещё чуть-чуть теории: Long polling.

ℹ️ Long polling — это технология, при которой клиент отправляет запрос к серверу, и сервер удерживает соединение открытым до тех пор, пока не появится новая информация для отправки или не истечёт время ожидания. После этого клиент сразу отправляет новый запрос.

Важно помнить:
1️⃣ В классическом виде работает на HTTP-протоколе.
2️⃣ Зависит от таймаутов. При наступлении таймаута клиент должен открыть новое соединение.
3️⃣ На одну итерацию получения данных требуется одно соединение (запрос-ответ).

P.S. Технология достаточно устаревшая, но всё ещё встречается на проектах.

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

❓Давно у нас не было вопросно-ответных постов (это он).

Напомню концепцию:
Если у вас возникают какие-то вопросы, касающиеся тематики канала, можете задавать их в комментариях.
Сложные кейсы, с которыми столкнулись в работе, теоретические вопросы, вопросы по курсам и т.д.

💬Я отвечу на них в комментариях (текстом или голосовым), а самые интересные разберу в видеоформате.

❓Ещё немного теории: SSE.

ℹ️ SSE (Server-Sent Events) — это механизм, позволяющий серверу асинхронно отправлять данные клиенту через HTTP-соединение.

Важно помнить:
1️⃣ Работает поверх HTTP-протокола. Поддерживает только метод GET.
2️⃣ Для установки соединения клиент должен отправить GET-запрос с заголовком Accept: text/event-stream.
3️⃣ При получении такого запроса сервер возвращает ответ 200, но не закрывает соединение. В это соединение сервер может досылать данные.

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

💬Немного обратной связи💬

Сейчас формирую программу интенсивов на сентябрь: будут новые темы и, по запросу, повтор популярных.

Если вы пропустили прошлые занятия из-за нехватки времени или просто не успели записаться – скажите, какие темы актуальны для вас.

Голосуйте в опросе, а самые востребованные включу в расписание.

Описание программ:
🔸Базы данных (с нуля);
🔸Проектирование REST API (junior);
🔸Брокеры сообщений (middle).

Опрос ниже 👇

P.S. Новые темы опубликую чуть позже.

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

❓Немного теории: WebSocket.

ℹ️ WebSocket — это самостоятельный протокол, предназначенный для двустороннего обмена сообщениями, c использованием постоянного соединения.

Важно помнить:
1️⃣ WebSocket — самостоятельный протокол;
2️⃣ Handshake — HTTP-запрос с заголовком Upgrade: websocket, который используется для установки соединения. Отправляется от клиента к серверу.
3️⃣ Ping/pong — механизм, с помощью которого сервер проверяет присутствие клиента на той стороне. Позволяет не держать "мертвые" соединения.

P.S. На этой неделе поговорим про real-time интеграции.

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

❗️Осталось 2 слота на понедельник 11.08 19:00 МСК на интенсив по REST API❗️

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

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

👉 Для записи переходите по ссылке.

Для тех, кто не понимает, о каких интенсивах речь, подробности тут.

UPD: 1 слот

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

🚩Ошибка при проектировании REST API: высокая связность клиентской части и модели данных.

Пример: У вас есть 2 таблицы: основная таблица со списком товаров и таблица с вариантами этих товаров (размеры, цвета и тд).

Задача: Получать список товаров отдельно и получать товары со всеми вариантами.

❌ Реализовать один универсальный метод и через дополнительные параметры "достраивать" join между таблицами, вытаскивая полный набор атрибутов.

✅ Реализовать два отдельных метода и возвращать в них только нужный набор атрибутов.

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

🚩Ошибка при проектировании REST API.

❌ Жестко привязывать параметры API к модели данных в БД.

✅ Упростить API, передавая минимально необходимый набор параметров, а дополнительную логику и преобразования делать на уровне логики сервиса.

Пример: добавление новой позиции в заказ с пересчётом суммы заказа.

1️⃣ В API передаем только параметры новой позиции, не нужно заранее рассчитывать новую сумму на фронте и передавать её на вход.
2️⃣ Сервис при получении такого запроса выполняет в одной транзакции 2 операции:
- Добавляет новую запись в таблицу позиций заказа;
- Обновляет сумму заказа в таблице заказов.

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

❗️Обновление программы интенсива по REST API❗️

✅ Добавил в программу работу со Swagger.

Теперь практика выглядит следующим образом:
🔸Проектируем REST API для нового сервиса;
🔸Описываем его в Swagger;
🔸Собираем вызовы сервиса через Postman (сервис реальный, с логикой и БД).

Следующий интенсив 11.08 в 19:00 МСК, записаться тут 👈

P.S. На брокерах сообщений осталось всего 2 места на 25.08, группа 24.08 полностью набрана.

UPD: На брокерах 1 слот.

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

❗️Второй способ решения интерактивного кейса.

Сам кейс тут 👈

✅ Шардирование основной БД для распределения операций записи по шардам.

1️⃣ Шардируем нашу основную БД;
2️⃣ В качестве ключа шардрования лучше всего подойдет hash — для равномерного распределения;
3️⃣ Операции записи распределятся по шардам, что кратно ускорит обработку потока сообщений.

⚠️ Диски под шардами должны быть физически изолированы.

P.S. Данный вариант имеет риск снова "упереться" в диск при неравномерном потоке сообщений (на его пиках).

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

❗️Остался один слот на это воскресенье 03.08 12:00 МСК на интенсив по REST API❗️

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

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

👉 Для записи переходите по ссылке.

Для тех, кто не понимает, о каких интенсивах речь, подробности тут.

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

❗️Один из способов решения интерактивного кейса.

✅ Промежуточная быстрая БД для быстрого разбора сообщений из топика с последующим переносом в основную БД.

1️⃣ Поднимаем Redis, в который будем писать все сообщения и накапливать батч для вставки в основную БД;
2️⃣ Отдельным воркером перекладываем батчи в основную БД одним запросом;
3️⃣ Не забываем про отказоустойчивость Redis;
4️⃣ Не забываем про мониторинг очереди сообщений в Redis.

P.S. Данный вариант подойдёт, если допустима небольшая задержка перед вставкой данных в основную БД.

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

💬 Интерактивный кейс: медленная скорость записи в БД

Кейс:
Имеется топик Kafka, который читает сервис. Задача сервиса — складывать все полученные сообщения в свою базу данных.

Проблема:
Из-за медленных дисков база не успевает сохранять все полученные данные, и скорость чтения топика замедляется — растёт лаг.

Задача:
Сделать так, чтобы база успевала записывать все данные и лаг на топике не возникал.

💬 В комментариях предлагайте свои варианты решения проблемы.

❗️А в следующих видео расскажу о своих вариантах и объясню, от чего отталкиваться при выборе решения.

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

🚩Ошибка проектирования: пренебрежение асинхронными взаимодействиями.

Пример: вам необходимо синхронизировать данные между сервисами внутри системы или получать обновления из внешних источников.

❌ Использовать готовые синхронные методы для обновления данных в целевых базах.
Такой подход может привести к потере части данных при большом потоке запросов.

✅ Для каждого потока данных реализовать отдельные топики\очереди в брокерах сообщений.
Вы не потеряете сообщения даже при временной недоступности сервиса консьюмера.

P.S. Не забывайте о паттернах, влияющих на гарантию доставки, о которых я рассказывал ранее.

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