🚩Кейс: Распил монолита на микросервисы (этап 6).

Включение из отпуска 🎣

1️⃣ Для всех сервисов, которые были реализованы на предыдущих этапах, необходимо повторно выполнить пункты 3-5, как для самостоятельных маленьких монолитов.

2️⃣ Провести рефакторинг модели данных, выделить отдельные микросервисы, снизить их связность за счет репликации.

Предыдущие части:
👉Этап 1;
👉Этап 2;
👉Этап 3;
👉Этап 4;
👉Этап 5.

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

🚩Кейс: Балансировка нагрузки на консьюмерах (Back Pressure на примере RabbitMQ)

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

1️⃣ Использовать параметр prefetch_count для ограничения числа поступающих сообщений на консьюмер.

2️⃣ Консьюмер получит указанное число сообщений.

3️⃣ Консьюмер вернёт ack (подтверждение) брокеру только после обработки всех полученных сообщений.

4️⃣ После получения ack брокер отправит следующую партию сообщений, соблюдая заданный prefetch_count.

P.S. В следующих видео расскажу про Back Pressure в Kafka.

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

🚩Кейс: Распил монолита на микросервисы (этап 7). Финальный :)

1️⃣ Необходимо провести рефакторинг REST API для взаимодействия микросервисов и фронта.

2️⃣ Минимизировать количество вызовов. Если фронт где-то использует несколько неоптимальных методов, то объединить их в один.

3️⃣ Снизить оверфетчинг. Это ситуация, когда клиент получает больше данных, чем ему действительно нужно для выполнения конкретной задачи.

Предыдущие части:
👉Этап 1;
👉Этап 2;
👉Этап 3;
👉Этап 4;
👉Этап 5;
👉Этап 6.

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

🏁 Короткий итог цикла видео по распилу монолита.

Небольшое рассуждение на тему необходимости распила монолита☝️

Все части:
👉Этап 1: Переход к трехзвенной архитектуре;
👉Этап 2: Покрытие тестами существующего функционала;
👉Этап 3: Рефакторинг модели данных;
👉Этап 4: Декомпозиция на сервисы;
👉Этап 5: Снижение связности;
👉Этап 6: Декомпозиция на микросервисы;
👉Этап 7: Рефакторинг REST API.

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

❓Знаете ли вы, как RPC работает на самом деле?

ℹ️ Ловите небольшой фрагмент из модуля, посвящённого интеграциям через RPC, в котором объясняю, как взаимодействуют компоненты и какие функции они выполняют.

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

❓Что выбрать при проектировании: синхронное или асинхронное взаимодействие?

Синхронное:
1️⃣ Клиент не может продолжать работу без ответа от сервера;
2️⃣ Простота разработки и отладки приоритетнее масштабируемости и высокой пропускной способности;
3️⃣ Транзакционность - жесткая последовательность исполняемых операций.

Асинхронное:
1️⃣ Исполнение длительных операций;
2️⃣ Требуется высокая пропускная способность и масштабируемость интеграции;
3️⃣ Необходимость снижения связности компонентов системы;
4️⃣ Исполнение фоновых задач.

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

🚩Кейс: Балансировка нагрузки на консьюмерах (Back Pressure на примере Apache Kafka)

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

1️⃣ Отключить автоматический коммит оффсета на консьюмере. Коммитить оффсет вручную, только после успешной обработки полученных сообщений.

2️⃣ Установить параметр max.poll.records для ограничения числа сообщений, получаемых консьюмером за один раз — батч.

3️⃣ Убедиться, что консьюмер успевает обработать весь батч за отведённое время, установленное в параметре max.poll.interval.ms (по умолчанию 5 минут).


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

❓Что такое партиционирование в БД?

ℹ️ Партиционирование — это метод разделения больших таблиц в базе данных на меньшие, более управляемые части для повышения производительности и упрощения работы с данными.

Основные типы партиционирования:
✅ По диапазону - данные разделяются по диапазону значений (например, по датам);
✅ По значениям - разделение по конкретным значениям атрибутов (например, по регионам);
✅ По хэшу - равномерное распределение по партициям с помощью хэш-функции.

P.S. Завтра расскажу реальный кейс, основанный на партиционировании.

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

🚩Кейс: Очистка устаревших данных в БД.

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

✅ Удаление целой партиции - почти мгновенная операция, гораздо быстрее, чем DELETE по условию. Вместо удаления каждой записи, СУБД просто "отцепляет" партицию как отдельную таблицу (аналог DROP).

Алгоритм реализации:
1️⃣ Создаем партиции по необходимым периодам, например ежедневно или ежемесячно;
2️⃣ Процедура очистки находит партиции, подходящие по критерий "устаревших";
3️⃣ Партиция удаляется целиком, без поиска записей внутри неё.

P.S. Лучше делать ночью, так как в момент операции таблица блокируется целиком. Это нужно для согласованности метаданных.

P.P.S. Если вы пропустили пост про партиционирование, жмите сюда :)

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

🚩Кейс: Построение отчетов по регионам.

ℹ️ Для решения такой задачи необходимо создавать партиции по ключу региона, это даст вам ряд преимуществ:

✅ Запрос от пользователя из конкретного региона будет сканировать только его партицию, что значительно ускорит построение отчета;
✅ Изоляция ресурсов при получении запросов по разным регионам в одно и тоже время;
✅ Партиция может полностью поместиться в локальный кэш, что существенно ускорит повторные запросы.

P.S. Не забывайте, что база для построения отчетов должна быть изолирована. Пост на эту тему тут.

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

🚩Кейс: Партиционирование при проведении A/B-тестирования.

ℹ️ Для удобной оценки эффективности новых алгоритмов лучше всего создавать партиции по сегментам пользователей. Тех пользователей, которые работают со старыми алгоритмами, относим в сегмент А. Тех, кто работает с новыми, относим в сегмент Б.

Таким образом получим:
✅ Быстрые выборки при агрегации метрик внутри сегмента (исследуемого алгоритма);
✅ Моментальное удаление тестовых данных после завершения тестирования.

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