‼️Открыта запись на практический интенсив по REST API‼️

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

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

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

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

‼️Открыта запись на практический интенсив по брокерам сообщений‼️

Тема: Брокеры сообщений.
Уровень: Middle.
Требуемые навыки: Понимание принципов работы распределённых систем.
Кол-во участников: до 4.
Длительность: ~3.5 часа.
Программа:
✅ Типы брокеров (модель обмена, гарантия доставки, умные/глупые брокеры);
✅ RabbitMQ;
✅ ApacheKafka;
✅ Transaсtional outbox;
✅ Обработка ошибок в асинхронных интеграциях.

Практика:
✅ Внедрение брокеров в распределенную систему;
✅ Описание формата взаимодействия.

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

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

🗓 Расписание всех интенсивов на август 🗓

🔸03.08 12:00 МСК (Воскресенье) — Проектирование REST API;
🔸04.08 19:00 МСК (Понедельник) — Базы данных;
🔸11.08 19:00 МСК (Понедельник) — Проектирование REST API;
🔸24.08 12:00 МСК (Воскресенье) — Брокеры сообщений;
🔸25.08 19:00 МСК (Понедельник) — Брокеры сообщений.

Подробная информация о программах в постах выше ☝️

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

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

❓До какого уровня стоит декомпозировать систему на микросервисы?

❌ Не стоит делать этого интуитивно, привязываясь к технологиям или бизнес-процессам.

✅ Моя концепция — декомпозировать систему до уровня одной транзакции. Как только вы понимаете, что дальнейшая декомпозиция приведёт к распределенным транзакциям в вашей системе, то стоит остановиться. Таким образом, вы сможете избежать проблем согласованности данных и внедрения сложных механизмов для работы с распределенными транзакциями, такими как SAGA.

P.S. Это, конечно, не серебряная пуля, но большинство кейсов однозначно покрывает.

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

🚩Ошибка проектирования: нарушение принципа независимости микросервисов.

❌ Если для обработки запроса вашему сервису необходимо обратиться в другие сервисы, то это может привести к каскадным сбоям системы. Плюс, такая модель создает жёсткую связность.

✅ Агрегация данных, полученных из нескольких сервисов на клиенте.
Такой подход можно использовать, когда нет необходимости в серверной фильтрации или пагинации.

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

👇Ниже приложу схемы для наглядности👇

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

❗️Информация по оставшимся слотам на интенсивах❗️

Проектирование REST API:
🔸3 места — 03.08 12:00 МСК (Воскресенье);
🔸4 места — 11.08 19:00 МСК (Понедельник).

Базы данных:
🔸3 места — 04.08 19:00 МСК (Понедельник).

Брокеры сообщений:
🔸3 места — 24.08 12:00 МСК (Воскресенье);
🔸2 места — 25.08 19:00 МСК (Понедельник).

Подробная информация о программах:
✅Проектирование REST API;
✅Базы данных;
✅Брокеры сообщений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сам кейс тут 👈

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UPD: 1 слот

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

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

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

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

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

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

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

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

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

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

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

Опрос ниже 👇

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

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