📌 7 шаблонов архитектуры, которые важно понимать СА 📌

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

Но в больших продуктовых компаниях, как банки, маркетплейсы, страховые и т.п., где преобладают сервисная (SOA) и микросервисная (MSA) архитектуры, аналитикам важно разбираться в этом вопросе.


👉 Обычно спрашивают знание этих шаблонов:
1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-Ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)


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


📚 В мини-книге к посту вы найдёте:
+ описание каждого подхода,
+ связи между ними,
+ картинки,
+ примеры.


Сохраняйте, изучайте и пользуйтесь!


P.S. А если интересна архитектура для кода, то рекомендую подкаст про Чистую архитектуру


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

🔴 Архитектура рекламной платформы: микросервисы, EDA, Kafka 🟢

В этом месяце будем проектировать архитектуру рекламной платформы #AdFlowGA 👩‍💻🧑‍💻


👉 Предыстория:

Пару лет назад в России стала обязательной маркировка интернет-рекламы: перед запуском объявление должно получить уникальный идентификатор ERID через оператора рекламных данных (ОРД), а сведения попадают в Единый реестр интернет-рекламы (ЕРИР), который ведёт Роскомнадзор.

Из-за этого теперь недостаточно просто завести объявление в кабинете Яндекс / ВК / Telegram — нужно пройти цепочку: маркировка → публикация → учёт → отчётность.


👉 Как это должно работать по шагам:

1. Создание креатива в платформе
текст/баннер/видео + целевая площадка, ссылка, параметры кампании.

2. Автопроверки
формат, запрещённые слова/URL, обязательные поля и др.

3. Ручная модерация
очередь, статусы, комментарии, возврат на доработку.

4. Регистрация рекламы в ОРД
получение ERID.

5. Публикация объявления на выбранной площадке
интеграция с рекламными API.

6. Активация рекламы + запуск биллинга
резерв/списание бюджета, старт учёта показов/кликов/расходов.

7. Сбор статистики с площадок + хранение истории изменений для отчётности и аудита.

8. Передача обязательных данных по статистике в ОРД/ЕРИР


👉 С чем именно мы будем работать на проекте:

1️⃣ Проектирование микросервисов
Как разделить на независимые части рекламную платформу.

2️⃣ API Gateway
Единая точка входа для мобильных и веб-клиентов.

3️⃣ Интеграции
С системами маркировками и платформами для размещения рекламы.

4️⃣ Оркестрация vs Хореография
Подходы к управлению процессами.

5️⃣ Брокеры RabbitMQ и Kafka
Когда и какой брокер выбрать, их устройство и ключевые принципы работы.

6️⃣ Схема архитектуры в С4
Оформим схемы в международных стандартах.


🧩 Будем делать схемы, продумывать потоки данных и разбирать, почему одно архитектурное решение здесь работает лучше другого.



👉 Хотите участвовать?

Подписывайтесь на @getanalysts и следите за хэштегами #AdFlowGA и #АрхитектураGA в ближайший месяц 🏷


Добро пожаловать в команду! 🤝


———-
P.S. Вчера был пост про 84 термина по архитектуре. Если на чём-то ещё важно сделать фокус и показать примеры, пишите в комментариях 👇

🗺️ 5 подходов к определению границ микросервисов 🗺️

Хорошая декомпозиция системы на микросервисы — это когда по каждому сервису понятно:
✔️ чем владеет (данные),
✔️ какие функции выполняет,
✔️ что он гарантирует (SLA),
✔️ и как реагирует на сбои.

Разберём 5 ключевых подходов к декомпозиции системы на микросервисы на примере проекта по управлению рекламой #AdFlowGA👇


———

1️⃣ По группам функций

Каждый микросервис объединяет логически связанные функции.

🔹 Сервис объявлений
Создание и редактирование креативов, версии, черновики, статусы.

🔹 ERID-сервис
Интеграция с ОРД, регистрация рекламы, хранение ERID, ретраи при ошибках.

🔹 Управление публикациями
Интеграции с рекламными API (VK, Telegram и др.), получение platformAdId.

🔹 Сервис биллинга
Резерв бюджета, списания, учёт показов, финансовая отчётность.

Подход понятный.
Но может игнорировать реальные доменные границы и различия в SLA.

———


2️⃣ По доменам (DDD — Bounded Context)

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

🔹 Домен “Управление объявлениями”
Креативы, статусы, версии, бизнес-правила переходов состояний.

🔹 Домен “Маркировка”
ERID, интеграция с ОРД, требования к отчётности, юридические ограничения.

🔹 Домен “Публикация”
Работа с API площадок, синхронизация статусов, дедупликация запросов.

🔹 Домен “Финансы”
Резервы, списания, корректировки, возвраты.

Важно:
разные домены = разные SLA и разные требования к отказоустойчивости.


———

3️⃣ По данным (Data Ownership)

Каждый сервис владеет своим набором сущностей.

🔹 Управление объявлениями
Ad, AdVersion, AdStatus.

🔹 Биллинг
Budget, Reservation, Transaction.

🔹 Публикации
PlatformAd, SyncStatus.

Никакой “общей БД на всех”.
Данные связаны по id (PK - первичным ключам).
Связь через брокеры + API.


———

4️⃣ По процессным границам

Границы сервисов можно выявить через группы сценариев, которые логически связаны и часто изменяются вместе.

🔹 Запуск рекламной кампании
Создание объявления, прохождение модерации, получение ERID, публикация на площадке, активация, запуск биллинга.

🔹 Управление кампанией
Приостановка и возобновление показов, изменение статуса, обновление параметров размещения.

🔹 Управление бюджетом
Начисление бюджета, резерв средств, списание, корректировки, возвраты.


———

5️⃣ По уровню нагрузки и SLA

Это уже архитектурная зрелость.

🔹 Сервис статистики
Высокая нагрузка на чтение, горизонтальное масштабирование.

🔹 Сервис публикаций
Много внешних API-вызовов, таймауты и задержки.

🔹 Биллинг
Повышенные требования к консистентности и надёжности.


———

Список микросервисов по каждой категории можно продолжить.


👉 Разные способы декомпозиции часто приводят к похожему набору сервисов.

Но основание для выделения сервиса должно быть зафиксировано в архитектурных принципах проекта.

Это поможет избежать неясностей и обеспечит гибкость при развитии проекта 🚀


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

Говорят, идеальных мужчин не существует 👀

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

Кто-то сидит за ноутбуком и решает то, что для других выглядит как «что вообще происходит?» 😏
Кто-то держит на себе семью, работу, ответственность и слово.


👉 Мужчины — это про опору.
Про силу, интеллект, юмор, собранность и поступки.
Про умение защитить, поддержать, решить проблему и не потеряться в сложный момент.


И да, отдельно хочется выделить мужчин из IT ❤️‍🔥
👉 с вами всегда есть о чем поговорить - от жизни до технологий,
👉 и вам правда всегда хочется принести что-нибудь вкусное к компьютеру, пока вы заняты своими важными делами 🍪🍕🥗


Спасибо вам, мужчины, что вы есть.
За заботу, надежность, характер и то самое ощущение: «рядом — настоящий мужчина»!
Вы такие везде, как в работе, так и в жизни!


С 23 Февраля! Очень вами гордимся! 💙


👉 Девушки, давайте поздравим наших коллег-мужчин ❤️‍🔥❤️‍🔥❤️‍🔥 под этим постом + в комментариях 😊


С добром и теплом,
Екатерина Ананьева,
и команда GetAnalyst

💥 Виды API: когда и какой выбрать 💥

API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом.

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


Основные виды API:
⚡ HTTP
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
⚡ SSE


В деталях 👇

⚡ HTTP API
Использует HTTP-протокол.
Часто это более “простые” API без строгого следования REST-подходу.
Во многих таких API чаще встречаются только методы GET / POST, но могут использоваться и другие.

Пример: Unisender


⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепции ресурсов и стандартных HTTP-методов (GET, POST, PUT, PATCH, DELETE и др.).

Это архитектурный стиль проектирования API поверх HTTP.

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

Пример: Wildberries


⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает стандартизированные подходы к безопасности и описанию операций.

Часто применяется в корпоративных системах (enterprise), где важны строгие контракты, формализация и совместимость, а также повышенная безопасность.

Сегодня для новых проектов SOAP выбирают реже, так как REST/gRPC часто проще и легче в реализации и сопровождении.

Пример: PayPal


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

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

Пример документации:
Яндекс.Погода


⚡ gRPC
Использует Protocol Buffers (protobuf) для сериализации данных и обычно работает поверх HTTP/2.

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

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

Пример: Dropbox от Google


⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.

Используется там, где нужен быстрый обмен событиями: чаты, уведомления, биржевые данные, игровые сценарии и т.д.

Пример: Binance Биржа


⚡ SSE (Server-Sent Events)
Механизм, при котором сервер может в реальном времени отправлять обновления клиенту по одному HTTP-соединению.

В отличие от WebSocket, SSE обычно используется для односторонней передачи данных (от сервера к клиенту).

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

Обычно проще в реализации, чем WebSocket, если не нужна двусторонняя связь.



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

✅ корректно описывать требования к интеграциям,

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

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

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

🌐 Load Balancer | Reverse Proxy | Forward Proxy | Service Mesh | Gateway 🌐

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

Давайте разберёмся в 5 ключевых компонентах высоконагруженных систем:


🔹 Load Balancer (балансировщик нагрузки)
Равномерно распределяет нагрузку между серверами, чтобы не было перегрузки и падений.
+ Принимает все входящие запросы.
+ Равномерно распределяет их по нескольким серверам.
+ Автоматически исключает из работы «упавшие» узлы.
👉 Благодаря этому система выдерживает пиковые нагрузки и остаётся доступной.


🔹 Reverse Proxy
Работает от имени сервера.
+ Принимает запросы от клиента и передаёт их в backend.
+ Скрывает внутреннюю инфраструктуру (клиент не знает адресов сервисов).
+ Может кэшировать ответы, чтобы уменьшить нагрузку.
👉 Часто используется вместе с балансировкой и как дополнительный уровень защиты.


🔹 Forward Proxy
Работает от имени клиента.
+ Прячет реальный адрес пользователя.
+ Может фильтровать запросы и блокировать нежелательные сайты.
+ Используется в компаниях для контроля доступа сотрудников в интернет.
👉 Ближе к «интернет-фильтру» или «корпоративному шлюзу». Защищает и контролирует клиента.


🔹 Service Mesh
Внутренняя «сеть» для общения микросервисов между собой.
+ Настраивает коммуникацию сервис-сервис без изменения кода.
+ Делает автоматическую балансировку и маршрутизацию внутри кластера.
+ Добавляет шифрование трафика, retries, circuit breaker, метрики.
👉 Полезен в Kubernetes, где много сервисов и вручную управлять связями уже невозможно.


🔹 API Gateway
Единая точка входа для всех клиентских запросов.
+ Проверяет авторизацию и токены.
+ Маршрутизирует запросы к нужным сервисам.
+ Ограничивает частоту запросов.
+ Может объединять ответы от разных микросервисов в один.
👉 Используется для централизованного приема API-запросов.


📌 Запоминайте эти сетевые+архитектурные термины и применяйте правильно в общении с разработчиками и архитекторами.

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

📌 8 Шаблонов Микросервисной архитектуры, о которых спрашивают 📌

1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.

2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.

3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.

4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.

5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.

6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.

7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.

8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.


⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.


Сохраните себе шпаргалку и используйте при проектировании архитектуры микросервисов, анализе своих проектов и подготовке к собеседованиям 🙌


Исходник: png | noscript (анимация)

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

Тем временем у меня пошёл 6-й месяц учёбы в Университете Джонса Хопкинса по AI 🤩


И это вообще не история “вот ChatGPT, сюда вставь готовый промпт”.

Нам показывают искусственный интеллект (AI) "под капотом", чтобы мы понимали, что именно происходит, когда модель “умно отвечает”.



За последние полгода я, кажется, написала больше кода, чем за 6 лет обучения в МИФИ 😅

Потому что работа с AI в роли разработчика реально “сдвигает” сознание: ты начинаешь видеть не только результат, но и механику.

И это не про “вайб-кодинг”.

Это формат:
+ делаем блок кода на Python под конкретную задачу - c AI или без,
+ разбираемся что сделали построчно,
+ делаем следующую задачу.

Делаем мини-проекты под разные домены: медицина, IT-компании, онлайн-торговля, финтех и другие.



Что было последние пару месяцев:

👉 Безопасная разработка приложений с AI
От защиты промптов и архитектуры до соблюдения законодательства.

👉 AI-агенты
Их можно делать без программирования. Но нам "магию" использовать не разрешили.
Всё запрограммировала, побесилась, но это было полезно для понимания как работает "магия", и как улучшить мою работу.

👉 MCP (Model Context Protocol)
Стандарт для интеграций LLM с системами и данными: как подключать инструменты и источники системно, и в каких случаях MCP уместен, а где проще и надёжнее традиционная интеграция.

👉 Fine-Tuning и RAG
Адаптируем нейросети под задачи бизнеса. Мне безумно понравились несколько практических задач, которые мы делали на Python!
В итоге одну из них решила добавить в финальный модуль по программированию для наших студентов на ИИ-Акселераторе 😍



В общем, учёба в Хопкинсе открыла для меня AI с той глубокой технической стороны, которая раньше вызывала вопросы.

До сих пор не знаю как я успеваю учиться.
Полноценных выходных не было давно 🙈
Но я точно знаю, что этот огромный вклад времени в обучение уже повлиял на мою работу и развитие 🙌

🚦 Всё про брокеры: как работают и зачем нужны 🚥

Брокеры — это посредники в передаче сообщений между системами или сервисами.

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


👉 Принцип работы:

1. Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель).

2. Сервис 2 в это время может быть перегружен или занят.

3. Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу.

4. Брокер сохраняет сообщение и ставит его в очередь к обработке.

5. Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его.

По сути брокеры - это временные Базы Данных,

которые гарантируют, что сообщения (данные) в них будут храниться, пока их не заберут и не обработают соответствующие системы или сервисы.
НО! Это всё же не БД, хранить в них сообщения до бесконечности не надо.


👉 Брокеры могут использоваться:
+ в сервисной и микросервисной архитектуре (хореография),
+ в событийно-ориентированной архитектуре (EDA),
+ когда нужна фоновая обработка событий в монолите,
+ для асинхронных интеграций.


👉 Брокеры сообщений предлагают два основных шаблона обмена данными:

1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.

2. Публикация-подписка (Publish/Subscribe)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.


Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.

Основные решения по брокерам на рынке:
✅ Apache Kafka
✅ RabbitMQ
✅ ActiveMQ
✅ Amazon MQ, Amazon SQS
✅ Яндекс Message Queue (YMQ) - аналог Amazon
✅ и другие.

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