🔥 3 реальных задачи, которые решают брокеры 🔥

Брокеры сообщений — это не просто очереди для передачи данных. Это ТОП-инструмент для построения асинхронных, отказоустойчивых и масштабируемых систем.

Они позволяют сервисам взаимодействовать без жесткой связанности, гарантируют доставку сообщений и помогают балансировать нагрузку.


Разберем три основных кейса, когда без брокеров не обойтись:

📌 1. Централизованная отправка уведомлений

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

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

👍 Почему так лучше?

+ Уменьшается связанность между сервисами
Если сервис уведомлений перегружен и не может принять сообщение сразу, оно сохранится в брокере.
Отправивший задачу на уведомление сервис не зависает в ожидании ответа, а продолжает работу.

+ Гибкое масштабирование
Когда 15 сервисов генерируют уведомления, для их обработки может понадобиться от 5 до 15 экземпляров сервиса уведомлений.
Без брокера система должна мгновенно реагировать на всплески нагрузки и увеличивать количество работающих копий сервиса уведомлений.
С брокером это не критично — сообщения просто ставятся в очередь и обрабатываются позже.

+ Можно легко добавлять новые каналы уведомлений (почта, пуши, SMS)
Например, в сервисе заказов сменился статус товара на "Доставлен".
Пользователь подписан на push, SMS и email-уведомления
Вместо того, чтобы сервису заказов делать три запроса или один долгий и ждать, пока каждое уведомление отправится, мы положим событие о смене статуса в брокер с пометкой о каналах доставки. А сервис уведомлений позже его обработает.
Таким образом, сервису заказов не придётся длительно ожидать ответ о доставке всех уведомлений.


📌 2. Централизованный сбор событий для мониторинга

Все сервисы отправляют в брокер данные о своих состояниях, ошибках, метриках. Из брокера эти события забирает система мониторинга, анализирует их и отправляет алерты DevOps-инженерам.

👍 Почему так лучше?

+ Все данные собираются в одном месте
Логи, ошибки, метрики и другие события поступают в брокер от всех сервисов, упрощая их обработку и анализ.

+ Гибкость и независимость от конкретной системы мониторинга
Можно легко подключать новые инструменты анализа и визуализации (Prometheus, ELK, Grafana и др.), не внося изменения в код сервисов, которые генерируют события.
Без брокера пришлось бы перенастраивать все сервисы на доставку в новый сервис мониторинга.

+ Гибкое масштабирование


📌 3. Реакция нескольких сервисов на одно событие

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

Пример:
При успешной оплате заказа в Интернет-Магазине сервис платежей отправляет событие "Оплата успешна" в брокер.

На это событие реагируют три сервиса:
▫️ Сервис заказов переводит статус заказа в "Оплачен"
▫️ Сервис склада списывает товары и создает задачу на сборку
▫️ Сервис уведомлений отправляет клиенту подтверждение об оплате

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

Сервис склада упал?
➖ Прервали процесс обработки события оплаты, потому что не получилось достучаться до склада
➖ Или потеряли уведомление о платеже и оно не дошло на склад

Брокер позволяет сделать процесс асинхронным и надежным.

👍 Почему так лучше?

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

+ Можно легко добавлять новые подписчики без изменений в коде исходного сервиса
Например, когда после успешной оплаты надо еще начислить бонусные баллы в сервисе лояльности, то мы добавим новый обработчик события из брокера, но не будем трогать код сервиса платежей.

+ Лучше отказоустойчивость
Нет риска, что событие не обработается в каком-либо сервисе - брокер даёт гарантию доставки.

+ Гибкое масштабирование


Итого:
Брокеры — залог гибкой, масштабируемой и отказоустойчивой архитектуры 👍

#АрхитектураGA

💫 Kafka - что надо знать для работы Системному аналитику 💫

Apache Kafka — это распределённая платформа потоковой обработки данных.

Предназначена для публикации, хранения и обработки событий/сообщений в реальном времени.


Основные компоненты:

✔️ Продюсеры (Producers)

1) Генерируют сообщения/события к обработке и отправляют в топики (темы).

2) Определяют, в какую партицию топика записывать данные: автоматически или по заданным правилам.

3) Могут быть чем угодно: микросервисы, устройства IoT и другие приложения.

4) Поддерживают режимы отправки:
+ Синхронный — ждёт подтверждения от Kafka перед отправкой следующего сообщения.
+ Асинхронный — отправляет сообщения без ожидания ответа.

5) Могут гарантировать доставку с разными уровнями подтверждения (acks):
+ acks=0 — без ожидания подтверждения (возможна потеря данных, высокая скорость).
+ acks=1 — подтверждение только от лидера партиции (среднее).
+ acks=all — подтверждение от всех реплик (максимальная надёжность).


✔️ Потребители (Consumers)

1) Подписываются на один или несколько топиков и получают сообщения/события.

2) Могут работать как отдельные клиенты или объединяться в группы (Consumer Groups) для параллельной обработки сообщений.

3) В группе консьюмеров каждый участник обрабатывает свою часть партиций.

4) Kafka гарантирует, что каждое сообщение будет обработано хотя бы одним потребителем в группе.

5) Модели доставки сообщений:
+ at-least-once — как минимум 1 раз, возможны дубликаты.
+ exactly-once — ровно один раз.


✔️ Топики (Topics) — логическая тема, куда продюсеры отправляют сообщения, а потребители их читают


✔️ Партиции (Partitions) — подмножество данных внутри топика, которое позволяет распределять нагрузку и масштабировать обработку сообщений. Каждый топик состоит из одной или нескольких партиций


✔️ Брокер (Broker) — сервер Kafka, который отвечает за хранение, управление и передачу данных внутри кластера


✔️ Кластер — это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных


#АрхитектураGA

📚 Мини-книга по Интеграциям для Системных аналитиков: самое важное 📚

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


Например, нам в приложении для медитаций надо сделать возможность оплаты подписки 🧘‍♀️

Получается, надо делать сложный банковский процессинг для проверки карт кучи банков, списания с них денег, проверки CVV, отправки проверочных кодов, безопасность приема и обработки платежей...?
В общем эту всю кучу банковских задач мы делать не хотим. Мы же не банк! 🥲

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


Главная идея интеграций:

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

👉 Виды интеграций:

1) по окружениям:
▫️ Внешние - когда мы хотим подключить к нашей системе чужую систему, от других разработчиков.
▫️ Внутренние
- у нас на проекте сервисная или микросервисная архитектура, и нам надо сделать так, чтобы сервисы обменивались данными друг с другом по API или через брокеры (очереди).
- мобильное приложение работает с данными благодаря интеграции с сервером по API.

2) по направлению:
▫️ Во внешние системы - когда мы используем API чужих систем.
▫️ К нашей системе - когда мы сами разрабатываем свой API, чтобы к нам подключались (например, по примеру выше, мы банк, и даем другим свой API для подключения)


👉 Способы обмена данными:
▫️ Синхронный - отправили данные и получили ответ сразу.
▫️ Асинхронный - отправили данные и продолжили работу без ожидания ответа. Обработка в фоне.


👉 Основные способы интеграции:
▫️ API
▫️ Библиотеки и SDK
▫️ Брокеры (очереди сообщений)
▫️ Файлы
▫️ Общая БД


📚 Подробнее о том, что такое интеграции и какие они бывают, рассказала в мини-книге с картинками и примерами.

Файл прикреплен к посту.

Загружаем, изучаем и запоминаем 👍

#ИнтеграцииGA

💫 ПРОБЛЕМЫ В РАБОТЕ С ЗАДАЧАМИ НА ИНТЕГРАЦИИ 💫

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

Этот эпизод представляет ценную информацию для начинающих и опытных системных аналитиков, стремящихся разобраться в работе с интеграционными задачами и обеспечить стабильное взаимодействие систем.

1:18 - Что такое интеграции?
4:25 - Роль системного аналитика в процессе работы с задачами на интеграции.
11:41 - Как изменилась работа с задачами на интеграции за последние годы?
16:49 - Написал требования в соответствии с API-документацией внешней системы, а потом оказалось, что работает не так.
19:40 - Интеграция работала в продакшн и всё было хорошо, а потом всё внезапно сломалось.
22:57 - Что делать если предстоит интегрироваться с системой у которой еще нет API, а сроки горят?
26:18 - Разработчик системы, с которой предстоит интегрироваться, не предоставляет API и доступы, а задачу нужно реализовать, потому что сроки (P.S. Влиять через заказчика на внешнюю команду при возможности).
28:07 - Что, если вы тот самый разработчик, у которого просят API, но вам пока не до этого?
29:21 - Платные подписки и использование внешних систем. Примеры: DaData.ru, сервисы SMS-рассылок с поштучной оплатой со счета заказчика и другие.
31:58 - Разные структуры данных в разных системах: как собрать всё в нашей системе воедино? Про агрегаторы.
36:07 - Высокие нагрузки и длительное ожидание ответов. Асинхронные запросы и вебхуки.
39:37 - Не работал с видом API, по которому предстоит интеграция (REST API, GraphQL, gRPC, SOAP API и WebSocket - основные, посмотрите на них).
42:02 - Заключение и рекомендации


Эпизод доступен в:

⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Apple Podcast
⏯ Castbox
⏯ Spotify
⏯ Amazon Music


Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!

🔷 User Stories: подход и применение в интеграциях 🔷

User Stories –

это формат описания требований с фокусом на конечного пользователя и его потребности.

Этот метод широко применяется в гибких методологиях разработки (Agile, Scrum) и помогает командам формулировать задачи так, чтобы они отражали реальную ценность для пользователей или стейкхолдеров.

Вместо детального технического описания требований, User Story фиксирует:

👉 цель,

которую хочет достичь пользователь,

👉 основные критерии приемки,

которые являются аналогом функциональных требований.

Это делает требования более понятными для всех участников проекта – от бизнеса до разработчиков.

Детализация требований может быть (и будет) сделана на следующих этапах аналитики и разработки.


👉 Пример User Story:
Как пользователь-арендатор платформы #BookingGA,
я хочу видеть отзывы по домам и квартирам, предлагаемым в ней,
чтобы принимать более взвешенное и уверенное решение перед началом аренды.

👉 Критерии приемки:
+ После окончания аренды пользователю предлагается оставить отзыв по бронированию:
++ при просмотре истории бронирований в приложении,
++ через email и push-уведомления.
+ При размещении отзыва пользователь может поставить количество звезд, написать текстовое сообщение и прикрепить фотографии.
+ …

🔷 Особенность User Stories в интеграционных проектах – это акцент не только на взаимодействии пользователей с системой, но и на том, как разные системы обмениваются данными.

При формулировке таких историй и их критериев приемки важно учитывать:
✅ 1. Событийный характер данных
✅ 2. Взаимодействие с API внешних систем
✅ 3. Авторизация систем и пользователей
✅ 4. Логирование и мониторинг
✅ 5. Требования к гарантии доставки
✅ 6. Обработка дубликатов данных
✅ 7. Обработка конфликтов данных
✅ 8. Ограничения и лимиты API внешних систем
✅ 9. Масштабируемость и обработка больших объемов данных


Подробности каждого пункта и примеры разобрала в мини-книге к посту 📚

#ИнтеграцииGA

🐺 Работа не волк, но может и загрызть 🐺

Еще год назад я думала, что главное — это успеть как можно больше.
Работала по 10-12 часов в день, почти без выходных.
Жила в режиме «ещё чуть-чуть, и можно выдохнуть».

Но потом в очередной раз поняла:

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

Уже не первое озарение.
И каждый раз с новой стороны.

👉 Именно поэтому сегодня моя дисциплина — это не только про работу, но и про здоровье, энергию и качество жизни.

Делюсь самым сокровенным.


◻️ Физическое здоровье

1. Спорт — неотъемлемая часть моей жизни уже почти 10 лет.
Даже если день загружен под завязку, я нахожу время подвигаться. Бегаю, делаю силовые, хожу на длинные прогулки.
Это не про «надо» — это про «если не сделаю, почувствую себя хуже».

2. Добавила регулярные чекапы.
Раз в год сдаю анализы, проверяю, какие показатели улучшились, а где капец.
В прошлом году нашелся дефицит железа. А еще слишком высокий уровень стресса.
Весь год работала над исправлением.
+ Витаминки и правильные продукты - мои лучшие друзья
+ Увеличение сна до 8+ часов (хотя всё ещё периодически косячу)
+ Два выходных в неделю без компьютера
В конце марта снова пойду проверять показатели.
Надеюсь, что ситуацию поправила.


◻️ Питание
С едой у меня вечно какая-то история.
Считаю калории, экспериментирую с выбором продуктов.
В этом году — полный отказ от кофе и алкоголя.
Пока похоже на интересный опыт и улучшение самочувствия.

Но самое неожиданное: год назад убрала из рациона молочку.
И впервые с подросткового возраста у меня чистая кожа. Ни один косметолог не дал такого результата! 😱
Приготовила сырники один раз за всё время, думала жаренный творог норм. Ага 🤣 Моё лицо дало реакцию на следующий день. На чипсы по неосторожности такой реакции нет, как на молоко))
У кого проблемы с кожей - рекомендую попробовать.
Привыкаешь со временем, но иногда скучаю 😅


◻️ Уход за собой
Дисциплина — это не только про работу и спорт, но и про заботу о себе.
Через "галочки" в ежедневнике каждый день заставляла себя пользоваться кремами, маслами для волос, делать маски.
Уже почти сделала рутиной это всё))
Для девушек это точно важно!!!
Ведь красота — это не только про внешность, но и про ощущение себя, самочувствие и качество жизни.


◻️ Ментальное здоровье

Отдыхать — это не слабость, а необходимость.

Путешествовать, делать выходные, спрашивать себя: «Как я себя чувствую?».
А если внутри хаос — не бояться пойти к психологу или коучу. Это реально помогает.

За 2 выходных в неделю мне до сих пор иногда стыдно. Но я работаю над этим и понимаю, что зато в будни я продуктивнее, и чувствую себя живее.

Работа в IT — круто, но порой стрессово.
Мы постоянно думаем, решаем задачи, держим в голове десятки процессов.
👉 И если не следить за своим состоянием, можно загнать себя так, что никакие достижения не принесут радости.
Работа загрызёт 🐺


💡 Итого:
Если не заботиться о себе, здоровье и энергия уйдут раньше, чем ты успеешь сказать «сгорел».
Так что следите за собой, проверяйтесь у врачей, вовремя отдыхайте и держите в рутине всё, что делает вас сильнее.


Берегите себя ❤️