💬 Итоги опроса 💬

Победил вариант: Новая технология, которой нет на проекте, но она идеально подходит под решение задачи.

Выделю стоп-факторы, из-за которых на реальном проекте не получится пойти по этому варианту:
1️⃣ Нехватка ресурсов на развёртывание новой технологии;
2️⃣ Отсутствие компетенций в команде для работы с новой технологией;
3️⃣ Сроки — внедрять новое дольше, чем использовать то, что уже работает.
4️⃣ Ограничения по использованию технологий. Например, ваш проект должен соответствовать требованиям ФСТЭК.

P.S. У меня на проектах всегда присутствуют 2-3 пункта из перечня выше, поэтому чаще приходится использовать имеющийся стэк.

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

❗️Осталось 2 места в группу выходного дня❗️

На новый интенсив "Функциональные требования" в группе 07.09 (воскресенье) осталось 2 места.

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

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

❓Горизонтальная масштабируемость в распределенных системах.

ℹ️ Горизонтальная масштабируемость — это способ увеличить производительность распределённой системы за счёт добавления новых экземпляров сервисов (подов) в вашей системе. Поды ваших сервисов работают параллельно, при этом производительность системы кратно увеличивается.

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

P.S. В следующих видео расскажу о преимуществах и недостатках такого подхода.

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

❓Горизонтальная масштабируемость — влияние на отказоустойчивость.

Если сервис работает в одном поде, то при проблемах с ним перестают работать все функции, за которые он отвечает.

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

Пример:
❌ В магазине работает одна касса, и в какой-то момент она зависает.
Итог: все покупатели ждут, пока придёт сотрудник и её перезагрузит.
✅ В магазине работают три кассы, но одна из них зависает.
Итог: покупатели просто переходят на соседние кассы.

P.S. Кто пропустил первую часть, она тут.

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

А вот и итоги последнего летнего месяца 🫡

Продолжаем расти, несмотря на отпуска 🎉

Статистика без учета интенсивов, так как там ученики повторяются:)

❗️После цикла постов о real-time интеграциях забыл сделать итоговый пост для удобства 🫠

Но лучше поздно, чем никогда:
🔸Теория WS;
🔸Теория SSE;
🔸Теория Long polling;
🔸Практическое применение WS;
🔸Практическое применение SSE;
🔸Практическое применение Long polling;
🔸Сравнение технологий.

🔤: Нужно ли углубляться в изучение данных технологий?

🔤: Мне кажется, что точно нужно знать об их существовании, отличиях и способах применения. Глубоко погружаться стоит только если вы столкнётесь с ними на реальном проекте.

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

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

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

Но есть хорошие новости:
✅ Функциональные требования 22.09 — осталось 3 места;
✅ По брокерам и REST API — места есть.

Частый вопрос от участников:
🔤: А что, если группа не наберется?

🔤: Проведу интенсив в любом случае! Даже для одного человека — сделаем полноценное персональное занятие 😉

Запись по ссылкам 👇
Брокеры сообщений
Функциональные требования
REST API

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

❓Горизонтальная масштабируемость — установка обновлений.

Если сервис работает в одном поде, то, в момент перезапуска для установки релиза, сервис перестает исполнять свои функции.

Если же сервис работает в нескольких подах, то обновление и перезапуск происходят поочерёдно. Это позволяет обеспечить непрерывную работу сервиса без потери функциональности.

Пример:
❌ В магазине работает одна касса. Требуется провести инкассацию. Кассу закрывают — все покупатели вынуждены ждать.
✅ В магазине работают три кассы. Инкассацию проводят поочерёдно. Покупатели продолжают оплачивать покупки у открытых касс.

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

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

Слоты начали активно занимать, выкладываю количество мест на данный момент:

☑️ Функциональные требования 07.09 — мест нет;
✅ Брокеры сообщений 08.09 — осталось 3 места;
✅ REST API 15.09 — осталось 4 места.
✅ Брокеры сообщений 21.09 — осталось 2 места;
✅ Функциональные требования 22.09 — осталось 3 места.


Запись по ссылкам 👇
Брокеры сообщений
Функциональные требования
REST API

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

❓Горизонтальная масштабируемость — экономия ресурсов.

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

Затем, после снижения нагрузки, вернуть количество подов к первоначальному.

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

Таким образом, вы добавляете ресурсы только там, где они нужны.

Пример:
✅ В магазине работают три кассы, начинается час-пик. Вы открываете ещё три кассы, чтобы успевать обслуживать покупателей. Час-пик прошёл — вы закрывате лишние кассы.

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

‼️Сегодня 19:00 МСК ‼️
Остались места на интенсив "Брокеры сообщений"

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

Практика:
✅ Проектируем внедрение брокеров в распределенную систему;
✅ Поднимаем RabbitMQ и ApacheKafka локально в docker;
✅ Учимся работать с ними через веб-интерфейс;
✅ Описываем формат взаимодействия в asyncapi.

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

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

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

❓Когда горизонтальная масштабируемость не поможет?

✅ Если сервис на выполнение одной задачи тратит кратно меньше ресурсов, чем выделено каждому поду, то горизонтальная масштабируемость будет увеличивать его производительность.

❌ Если в сервис поступает задача, на выполнение которой необходимо больше ресурсов (например, оперативной памяти), чем выделено каждому поду, то увеличение количества подов не поможет в обработке такой задачи.
В таком случае нужно прибегнуть к вертикальной масштабируемости, то есть добавить ресурсов существующим подам, вместо увеличения их количества.

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

❗️Обновленная информация по интенсивам❗️

Выкладываю количество мест на данный момент:

✅ REST API 15.09 — осталось 4 места.
☑️ Брокеры сообщений 21.09 — мест нет;
✅ Функциональные требования 22.09 — осталось 3 места.

Запись по ссылкам 👇
Функциональные требования
REST API

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

❓Возможная проблема при использовании горизонтальной масштабируемости

✅ Один под:
Сервис работает в одном экземпляре — задачи исполняются ровно в той последовательности, в которой поступают. Все строго и предсказуемо.

❌ Несколько подов:
Сервис масштабирован — порядок исполнения задач между разными подами не гарантируется.

Почему это проблема?

Представьте:
🔸Запрос А: «Списать 100 рублей»
🔸Запрос Б: «Заблокировать карту»

Если Б выполнится раньше А из-за параллельной обработки в разных подах — получим ошибку при исполнении запроса А.

P.S. Игнорирование этого вопроса — прямой путь к рассинхрону данных и багам, которые очень сложно отловить.

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

❗️Итог по горизонтальной масштабируемости

Подвел небольшой итог по двухнедельному циклу видео.
Все посты собрал в один, чтобы было удобно ориентироваться:

🔸Что такое горизонтальная масштабируемость;
🔸Влияние на отказоустойчивость;
🔸Влияние на установку релизов;
🔸Экономия ресурсов;
🔸Горизонтальная vs Вертикальная масштабируемость;
🔸Неконсистентность данных.

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

💬 Интерактивный кейс: полнотекстовый поиск на больших объемах

Кейс:
Имеем базу данных, в которую записывается ~1 млрд сообщений в сутки. Средний размер одного сообщения 2кб. Срок хранения 30 дней.

Задача:
Внедрить полнотекстовый поиск по сообщениям.

Важно:
Время работы поиска не должно превышать 1 секунду.

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

❗️В следующих видео расскажу вариант решения и отдельно разберу все его этапы.

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

❗️3 последних места на интенсивах сентября❗️

👉 Функциональные требования 22.09 19:00 МСК 👈

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

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

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

Запись тут 👇
Функциональные требования

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

💬 Решение: полнотекстовый поиск на больших объемах.

1️⃣ Выбрать технологию подходящую под задачу и её масштабы. Тут подойдёт Elasticsearch.
2️⃣ Разделить чтение и запись. Записывать данные будем в основную БД, а поиск осуществлять из Elasticsearch.
3️⃣ Настроить репликацию данных от основного сервиса в Elasticsearch.
4️⃣ Внедрить сервис для потокового обогащения событий, чтобы приводить их в удобный для поиска формат.
5️⃣ Для наполнения хранилища Elasticsearch использовать коробочное решение Kafka Connect Elasticsearch Sink, которое будет читать топик с обогащенными сообщениями и через Bulk API отправлять данные в Elasticsearch.

ℹ️ Bulk API — это высокопроизводительный интерфейс для массовой асинхронной обработки больших объёмов данных.

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

P.S. В следующих видео разберу отдельно каждый этап. Укажу на нюансы, которые нужно учитывать, а также посчитаю примерное количество ресурсов для каждого участка.

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