Немного юмора в длинные выходные :)
Не просто так я на всех видео говорю, что все индивидуально 🤣
Системный анализ | Дмитрий Помаскин
Не просто так я на всех видео говорю, что все индивидуально 🤣
Системный анализ | Дмитрий Помаскин
😁13👍2🔥2
Поскольку курс по интеграциям ещё не был официально запущен, я решил опробовать на нём новый формат.
Вместо классических тарифов я предлагаю три гибких варианта, которые открывают доступ к модулям поэтапно.
Теперь вы можете выбирать только те темы, которые вам действительно интересны, — так вы не переплачиваете за лишнее и учитесь именно тому, что нужно.
Junior (12 890 ₽) - уже доступен для обучения:
✅ Введение в системные интеграции;
✅ Форматы данных в интеграциях;
✅ REST / SOAP / GraphQL;
✅ Интеграционные шины.
Middle (22 480 ₽) - уже доступен для обучения:
✅ Все модули из тарифа Junior;
✅ Брокеры сообщений;
✅ RPC (Remote Procedure Call);
✅ Real-time взаимодействие (WS, Long Polling, SSE).
Senior (38 790 ₽) - будет доступен в ближайшее время:
✅ Все модули из тарифов Junior и Middle;
✅ Интеграция на уровне БД;
✅ Безопасность в интеграциях;
✅ Паттерн Circuit Breaker;
✅ Observability (Наблюдаемость) интеграций;
✅ API-first подход и Swagger.
Записаться можно тут :)
P.S. Те, кто уже оформил предзапись, автоматически переведены на тариф Senior.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍8🔥6
Media is too big
VIEW IN TELEGRAM
Длинные выходные, значит, долго не было разборов, поэтому ловите разбор кейса с собеседования на 17 минут :)
🚩Кейс: Проектирование интеграций для банковской системы.
Бизнес-процесс:
1. Клиент отправляет заявку на выпуск новой карты.
2. Мы должны проверить клиента через службу безопасности.
3. В случае успеха, выпустить карту.
4. Доставить карту клиенту.
5. На всех этапах необходимо уведомлять клиента об изменении статуса.
Задача:
Спроектировать интеграции между сервисами банка.
Системный анализ | Дмитрий Помаскин
🚩Кейс: Проектирование интеграций для банковской системы.
Бизнес-процесс:
1. Клиент отправляет заявку на выпуск новой карты.
2. Мы должны проверить клиента через службу безопасности.
3. В случае успеха, выпустить карту.
4. Доставить карту клиенту.
5. На всех этапах необходимо уведомлять клиента об изменении статуса.
Задача:
Спроектировать интеграции между сервисами банка.
Системный анализ | Дмитрий Помаскин
2🔥8👍4👏4
В честь своего дня рождения подготовил для вас промокод BDAY, который даёт скидку 31%
Действует на любой курс и на любой тариф.
У промокода всего 5 активаций.
Использовать тут 👈
P.S. Напоминаю, что для тех, кто хочет повысить свой тариф с промокодом, есть видеоинструкция.
UPD: Осталось 3 активации :)
UPD2: Осталась 1 активация.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥6
This media is not supported in your browser
VIEW IN TELEGRAM
🚩Кейс: Распил монолита на микросервисы (этап 6).
Включение из отпуска 🎣
1️⃣ Для всех сервисов, которые были реализованы на предыдущих этапах, необходимо повторно выполнить пункты 3-5, как для самостоятельных маленьких монолитов.
2️⃣ Провести рефакторинг модели данных, выделить отдельные микросервисы, снизить их связность за счет репликации.
Предыдущие части:
👉Этап 1;
👉Этап 2;
👉Этап 3;
👉Этап 4;
👉Этап 5.
Системный анализ | Дмитрий Помаскин
Включение из отпуска 🎣
1️⃣ Для всех сервисов, которые были реализованы на предыдущих этапах, необходимо повторно выполнить пункты 3-5, как для самостоятельных маленьких монолитов.
2️⃣ Провести рефакторинг модели данных, выделить отдельные микросервисы, снизить их связность за счет репликации.
Предыдущие части:
👉Этап 1;
👉Этап 2;
👉Этап 3;
👉Этап 4;
👉Этап 5.
Системный анализ | Дмитрий Помаскин
🔥6👍3
Media is too big
VIEW IN TELEGRAM
🚩Кейс: Балансировка нагрузки на консьюмерах (Back Pressure на примере RabbitMQ)
⚠️ Чтобы консьюмер не пытался обработать больше сообщений, чем позволяют его ресурсы, необходимо ограничить количество одновременно получаемых сообщений.
1️⃣ Использовать параметр prefetch_count для ограничения числа поступающих сообщений на консьюмер.
2️⃣ Консьюмер получит указанное число сообщений.
3️⃣ Консьюмер вернёт ack (подтверждение) брокеру только после обработки всех полученных сообщений.
4️⃣ После получения ack брокер отправит следующую партию сообщений, соблюдая заданный prefetch_count.
P.S. В следующих видео расскажу про Back Pressure в Kafka.
Системный анализ | Дмитрий Помаскин
⚠️ Чтобы консьюмер не пытался обработать больше сообщений, чем позволяют его ресурсы, необходимо ограничить количество одновременно получаемых сообщений.
1️⃣ Использовать параметр prefetch_count для ограничения числа поступающих сообщений на консьюмер.
2️⃣ Консьюмер получит указанное число сообщений.
3️⃣ Консьюмер вернёт ack (подтверждение) брокеру только после обработки всех полученных сообщений.
4️⃣ После получения ack брокер отправит следующую партию сообщений, соблюдая заданный prefetch_count.
P.S. В следующих видео расскажу про Back Pressure в Kafka.
Системный анализ | Дмитрий Помаскин
2🔥9👍2
This media is not supported in your browser
VIEW IN TELEGRAM
🚩Кейс: Распил монолита на микросервисы (этап 7). Финальный :)
1️⃣ Необходимо провести рефакторинг REST API для взаимодействия микросервисов и фронта.
2️⃣ Минимизировать количество вызовов. Если фронт где-то использует несколько неоптимальных методов, то объединить их в один.
3️⃣ Снизить оверфетчинг. Это ситуация, когда клиент получает больше данных, чем ему действительно нужно для выполнения конкретной задачи.
Предыдущие части:
👉Этап 1;
👉Этап 2;
👉Этап 3;
👉Этап 4;
👉Этап 5;
👉Этап 6.
Системный анализ | Дмитрий Помаскин
1️⃣ Необходимо провести рефакторинг REST API для взаимодействия микросервисов и фронта.
2️⃣ Минимизировать количество вызовов. Если фронт где-то использует несколько неоптимальных методов, то объединить их в один.
3️⃣ Снизить оверфетчинг. Это ситуация, когда клиент получает больше данных, чем ему действительно нужно для выполнения конкретной задачи.
Предыдущие части:
👉Этап 1;
👉Этап 2;
👉Этап 3;
👉Этап 4;
👉Этап 5;
👉Этап 6.
Системный анализ | Дмитрий Помаскин
👍7🔥7👏3
Media is too big
VIEW IN TELEGRAM
🏁 Короткий итог цикла видео по распилу монолита.
Небольшое рассуждение на тему необходимости распила монолита☝️
Все части:
👉Этап 1: Переход к трехзвенной архитектуре;
👉Этап 2: Покрытие тестами существующего функционала;
👉Этап 3: Рефакторинг модели данных;
👉Этап 4: Декомпозиция на сервисы;
👉Этап 5: Снижение связности;
👉Этап 6: Декомпозиция на микросервисы;
👉Этап 7: Рефакторинг REST API.
Системный анализ | Дмитрий Помаскин
Небольшое рассуждение на тему необходимости распила монолита☝️
Все части:
👉Этап 1: Переход к трехзвенной архитектуре;
👉Этап 2: Покрытие тестами существующего функционала;
👉Этап 3: Рефакторинг модели данных;
👉Этап 4: Декомпозиция на сервисы;
👉Этап 5: Снижение связности;
👉Этап 6: Декомпозиция на микросервисы;
👉Этап 7: Рефакторинг REST API.
Системный анализ | Дмитрий Помаскин
1🔥10👍7👏1
Media is too big
VIEW IN TELEGRAM
❓Знаете ли вы, как RPC работает на самом деле?
ℹ️ Ловите небольшой фрагмент из модуля, посвящённого интеграциям через RPC, в котором объясняю, как взаимодействуют компоненты и какие функции они выполняют.
Системный анализ | Дмитрий Помаскин
ℹ️ Ловите небольшой фрагмент из модуля, посвящённого интеграциям через RPC, в котором объясняю, как взаимодействуют компоненты и какие функции они выполняют.
Системный анализ | Дмитрий Помаскин
🔥11👍5👏1
Media is too big
VIEW IN TELEGRAM
❓Что выбрать при проектировании: синхронное или асинхронное взаимодействие?
Синхронное:
1️⃣ Клиент не может продолжать работу без ответа от сервера;
2️⃣ Простота разработки и отладки приоритетнее масштабируемости и высокой пропускной способности;
3️⃣ Транзакционность - жесткая последовательность исполняемых операций.
Асинхронное:
1️⃣ Исполнение длительных операций;
2️⃣ Требуется высокая пропускная способность и масштабируемость интеграции;
3️⃣ Необходимость снижения связности компонентов системы;
4️⃣ Исполнение фоновых задач.
Системный анализ | Дмитрий Помаскин
Синхронное:
1️⃣ Клиент не может продолжать работу без ответа от сервера;
2️⃣ Простота разработки и отладки приоритетнее масштабируемости и высокой пропускной способности;
3️⃣ Транзакционность - жесткая последовательность исполняемых операций.
Асинхронное:
1️⃣ Исполнение длительных операций;
2️⃣ Требуется высокая пропускная способность и масштабируемость интеграции;
3️⃣ Необходимость снижения связности компонентов системы;
4️⃣ Исполнение фоновых задач.
Системный анализ | Дмитрий Помаскин
🔥9👍5
Как вы смотрите на онлайн-встречу в небольшой группе (от 4 до 6 человек)?
1. Один интенсив — одна тема и необходимый уровень. Например, "Проектирование БД (junior)".
2. Дату и время я объявлю заранее, а также открою запись.
3. Длительность — 3-4 часа.
Как будет проходить онлайн-занятие:
1. Теоретическая часть (20-30 минут).
2. Практическая: разбираем подробно несколько кейсов (20-30 минут).
3. Самостоятельная работа: участники решают практические задания (60-90 минут).
4. Итоги: вместе проверяем решения всех участников с разбором каждого варианта (60-90 минут).
Все материалы (запись конференции, задания с моими исправлениями и презентация) остаются вам.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥17👍8👏1
Интересен ли вам такой формат прокачки навыков? ☝️
Anonymous Poll
75%
Да, можно быстро прокачаться в нужных темах
7%
Нет, предпочитаю комплексные курсы
17%
Какое обучение? Я тут за контентом :)
Media is too big
VIEW IN TELEGRAM
🚩Кейс: Балансировка нагрузки на консьюмерах (Back Pressure на примере Apache Kafka)
⚠️ Чтобы консьюмер не пытался обработать больше сообщений, чем позволяют его ресурсы, необходимо ограничить количество одновременно получаемых сообщений.
1️⃣ Отключить автоматический коммит оффсета на консьюмере. Коммитить оффсет вручную, только после успешной обработки полученных сообщений.
2️⃣ Установить параметр max.poll.records для ограничения числа сообщений, получаемых консьюмером за один раз — батч.
3️⃣ Убедиться, что консьюмер успевает обработать весь батч за отведённое время, установленное в параметре max.poll.interval.ms (по умолчанию 5 минут).
Системный анализ | Дмитрий Помаскин
⚠️ Чтобы консьюмер не пытался обработать больше сообщений, чем позволяют его ресурсы, необходимо ограничить количество одновременно получаемых сообщений.
1️⃣ Отключить автоматический коммит оффсета на консьюмере. Коммитить оффсет вручную, только после успешной обработки полученных сообщений.
2️⃣ Установить параметр max.poll.records для ограничения числа сообщений, получаемых консьюмером за один раз — батч.
3️⃣ Убедиться, что консьюмер успевает обработать весь батч за отведённое время, установленное в параметре max.poll.interval.ms (по умолчанию 5 минут).
Системный анализ | Дмитрий Помаскин
🔥9👍6
Media is too big
VIEW IN TELEGRAM
❓Есть ли гарантия доставки при использовании брокеров?
⚠️ На самом деле, брокеры не гарантируют нам доставку.
Они гарантируют, что сообщение не потеряется на уровне транспорта.
Для того, чтобы обеспечить гарантию доставки, нужны:
✅ Гарантия отправки сообщения продюсером - паттерн Transactional Outbox;
✅ Гарантия обработки сообщения консьюмером - механизм Back Pressure.
Чтобы не искать, ссылки тут👇
🔸Transactional Outbox;
🔸Back Pressure в RabbitMQ;
🔸Back Pressure в Apache Kafka.
Системный анализ | Дмитрий Помаскин
⚠️ На самом деле, брокеры не гарантируют нам доставку.
Они гарантируют, что сообщение не потеряется на уровне транспорта.
Для того, чтобы обеспечить гарантию доставки, нужны:
✅ Гарантия отправки сообщения продюсером - паттерн Transactional Outbox;
✅ Гарантия обработки сообщения консьюмером - механизм Back Pressure.
Чтобы не искать, ссылки тут
🔸Transactional Outbox;
🔸Back Pressure в RabbitMQ;
🔸Back Pressure в Apache Kafka.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍4
(Напоминаю, что продолжительность в районе 3-х часов)
Anonymous Poll
47%
Будние дни, после 19:00 МСК
60%
Выходные дни
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
❓Что такое партиционирование в БД?
ℹ️ Партиционирование — это метод разделения больших таблиц в базе данных на меньшие, более управляемые части для повышения производительности и упрощения работы с данными.
Основные типы партиционирования:
✅ По диапазону - данные разделяются по диапазону значений (например, по датам);
✅ По значениям - разделение по конкретным значениям атрибутов (например, по регионам);
✅ По хэшу - равномерное распределение по партициям с помощью хэш-функции.
P.S. Завтра расскажу реальный кейс, основанный на партиционировании.
Системный анализ | Дмитрий Помаскин
ℹ️ Партиционирование — это метод разделения больших таблиц в базе данных на меньшие, более управляемые части для повышения производительности и упрощения работы с данными.
Основные типы партиционирования:
✅ По диапазону - данные разделяются по диапазону значений (например, по датам);
✅ По значениям - разделение по конкретным значениям атрибутов (например, по регионам);
✅ По хэшу - равномерное распределение по партициям с помощью хэш-функции.
P.S. Завтра расскажу реальный кейс, основанный на партиционировании.
Системный анализ | Дмитрий Помаскин
🔥12👍6
Media is too big
VIEW IN TELEGRAM
🚩Кейс: Очистка устаревших данных в БД.
❌ Простой запрос на поиск устаревших данных может быть медленным и тяжеловесным на больший объемах.
✅ Удаление целой партиции - почти мгновенная операция, гораздо быстрее, чем DELETE по условию. Вместо удаления каждой записи, СУБД просто "отцепляет" партицию как отдельную таблицу (аналог DROP).
Алгоритм реализации:
1️⃣ Создаем партиции по необходимым периодам, например ежедневно или ежемесячно;
2️⃣ Процедура очистки находит партиции, подходящие по критерий "устаревших";
3️⃣ Партиция удаляется целиком, без поиска записей внутри неё.
P.S. Лучше делать ночью, так как в момент операции таблица блокируется целиком. Это нужно для согласованности метаданных.
P.P.S. Если вы пропустили пост про партиционирование, жмите сюда :)
Системный анализ | Дмитрий Помаскин
❌ Простой запрос на поиск устаревших данных может быть медленным и тяжеловесным на больший объемах.
✅ Удаление целой партиции - почти мгновенная операция, гораздо быстрее, чем DELETE по условию. Вместо удаления каждой записи, СУБД просто "отцепляет" партицию как отдельную таблицу (аналог DROP).
Алгоритм реализации:
1️⃣ Создаем партиции по необходимым периодам, например ежедневно или ежемесячно;
2️⃣ Процедура очистки находит партиции, подходящие по критерий "устаревших";
3️⃣ Партиция удаляется целиком, без поиска записей внутри неё.
P.S. Лучше делать ночью, так как в момент операции таблица блокируется целиком. Это нужно для согласованности метаданных.
P.P.S. Если вы пропустили пост про партиционирование, жмите сюда :)
Системный анализ | Дмитрий Помаскин
🔥10👍5
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥17👍5
Media is too big
VIEW IN TELEGRAM
🚩Кейс: Построение отчетов по регионам.
ℹ️ Для решения такой задачи необходимо создавать партиции по ключу региона, это даст вам ряд преимуществ:
✅ Запрос от пользователя из конкретного региона будет сканировать только его партицию, что значительно ускорит построение отчета;
✅ Изоляция ресурсов при получении запросов по разным регионам в одно и тоже время;
✅ Партиция может полностью поместиться в локальный кэш, что существенно ускорит повторные запросы.
P.S. Не забывайте, что база для построения отчетов должна быть изолирована. Пост на эту тему тут.
Системный анализ | Дмитрий Помаскин
ℹ️ Для решения такой задачи необходимо создавать партиции по ключу региона, это даст вам ряд преимуществ:
✅ Запрос от пользователя из конкретного региона будет сканировать только его партицию, что значительно ускорит построение отчета;
✅ Изоляция ресурсов при получении запросов по разным регионам в одно и тоже время;
✅ Партиция может полностью поместиться в локальный кэш, что существенно ускорит повторные запросы.
P.S. Не забывайте, что база для построения отчетов должна быть изолирована. Пост на эту тему тут.
Системный анализ | Дмитрий Помаскин
🔥6👍2