✨ Монолит ⚔ Сервисы (SOA) ⚔ Микросервисы (MSA) ✨


👉 Архитектура

◽️ Монолит:
Один большой блок - единая кодовая база Backend.
Вся логика в одном месте.

🟡 SOA:
Отдельные сервисы с независимыми кодовыми базами.
Логика распределена.
В SOA сервисы крупные и многофункциональные, их можно назвать "микромонолитами".

💚 MSA:
Небольшие, автономные сервисы, каждый из которых отвечает за управление одной сущностью, процессом или задачей.
В MSA сервисы более узкоспециализированные по сравнению с SOA.

Сравнение сервисов в SOA и MSA на примерах:

🔹 Каталог товаров
SOA:
+ Сервис "Каталог" – управляет товарами, категориями, характеристиками, поиском и рекомендациями.
MSA:
+ Сервис управления товарами – добавляет, редактирует, удаляет товары
+ Сервис поиска – отвечает только за фильтрацию, поиск и выдачу результатов
+ Сервис рекомендаций – анализирует покупки пользователей и предлагает похожие товары

🔹 Корзина покупок
SOA:
+ Сервис "Корзина" – хранит товары пользователя, управляет ценами и скидками
MSA:
+ Сервис корзины – добавляет и удаляет товары.
+ Сервис расчёта цен – отдельно высчитывает итоговую сумму с учётом акций, налогов и доставки
+ Сервис промокодов и скидок – управляет купонами, скидками, программами лояльности



------------------

👉 База данных

◽️ Монолит:
Обычно одна на всю систему, но может быть и больше.

🟡 SOA:
Сервисы могут иметь общую БД или отдельные схемы внутри одной БД.

💚 MSA:
У каждого микросервиса своя БД.

Сравнение SOA и MSA:
Например, обновление платежного модуля в интернет-магазине с MSA не затронет каталог товаров, так как у них разные БД. В то время как в SOA архитектуре могут быть проблемы с обновлениями из-за наличия общей БД.



------------------

👉 Независимость, масштабируемость и отказоустойчивость

◽️ Монолит:
Если отказывает что-то в монолите, то он ломается целиком.
Релиз обновлений приводит к полной недоступности всего Backend.
Сложно масштабировать:
- постоянно надо добавлять новые мощности (память, ядра и другие) к существующему серверу при добавлении новых функций,
- если запущено несколько параллельно работающих копий монолита, то при росте пользователя, надо запускать новую дорогую копию.


🟡 SOA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса. Но могут быть сложности с отключением нескольких сервисов, когда выполняются обновления общих БД.
Можно масштабировать каждую БД и сервис по мере необходимости - т.е. если растет нагрузка на каталог товаров, то запустим больше копий только этого сервиса, а не всей системы.


💚 MSA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса, за счет собственной БД сложностей нет.
Можно масштабировать каждую БД и сервис по мере необходимости, как в SOA.



------------------

👉 Взаимодействие

◽️ Монолит:
+ внутреннее, через вызов процедур и функций в одном коде.


🟡💚 SOA и MSA:
+ напрямую по API (REST, gRPC и другие),
+ через шину данных ESB,
+ через API-сервисы, в том числе можно использовать API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.



------------------

Когда лучше монолит, когда SOA, а когда MSA?

Когда монолит?
✅ Если у вас стартап и ограниченный бюджет.
✅ Нет опытных специалистов и архитекторов, кто работал с MSA.
✅ Нужно сделать быстро и протестировать гипотезу.
✅ Нет высокой нагрузки – мало пользователей.

Когда SOA?
✅ Большая корпоративная система с интеграциями.
✅ Если в компании уже используется ESB.
✅ Не требуется высокая скорость изменений – SOA сложнее менять, так как сервисы могут зависеть от общей БД или централизованных решений.

Когда MSA?
✅ Нужна высокая скорость изменений и независимость команд.
✅ Нагрузка на отдельные функции распределена неравномерно – например, поиск товаров требует больше вычислительных мощностей, чем расчёт скидок.
✅ Отказоустойчивость критически важна.
✅ Частые релизы.


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

📄 Про собеседования, резюме и вилки ЗП 📄

Проходить собеседования - тоже навык, и его надо оттачивать.

Но эту тему я почти не поднимаю в канале, так как я больше "суровый технарь", который передаёт технические навыки и опыт работы 😁

А чтобы всегда быть в курсе, как пройти через HR на техническое собеседование и самопрезентовать себя, понимать, как менять карьеру и тактично спрашивать о большей ЗП.

Я рекомендую посмотреть подборку материалов, не моего авторства, по резюме, собеседованиям и оценке своей ЗП:

🔴Ключевые лайфхаки по резюме и его ОШИБКИ
🔴Нужны ли сопроводительные и что там писать
🔴Как отвечать на вопрос «Расскажите о себе»
🔴Как вести себя с неадекватом на собесе
🔴Как рассказывать о своем факапе?
🔴Какие книги почитать в т.ч. для успешного прохождения собеседований?
🔴Реальные примеры офферов бизнес и системным аналитиков до 500к

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

💚 Swagger - Open API - Практическое руководство. Часть 3 💚

Ранее опубликовано:
🔗 Часть 1. Регистрация аккаунта и создание демо-проекта
🔗 Часть 2. Создание собственного проекта и работа с базовыми настройками, первые строки кода

В этом посте:
👉 Часть 3. Описание методов POST и GET по спецификации OpenAPI
файл прикреплен к посту

Что внутри:
✔️ Разберетесь с блоками кода paths и components в OpenAPI
✔️ Получите готовый документ API-документации для личного портфолио с двумя описанными методами
✔️ Получите реальный опыт работы со Swagger / OpenAPI

⏳ Время на изучение и практику:
🕓 60 минут — на работу с заданиями строго по руководству, где есть подсказки по каждому шагу
🕓 +60 минут, если хотите выполнить ДЗ и создать личный демо-проект для портфолио


Пост не просто для сохранения, а для реального улучшения вашего технического опыта работы! 🙌

#RestApiGA

💥 Разбор спорных вопросов по REST API с проектов и собеседований: исследуем Trello и Todoist 💥

Как понять, что мы проектируем REST API правильно? Никак. Смотреть на публичную API‑документацию крупных систем, диссертацию Роя Филдинга, или на то, что уже есть в проекте. И исходя из этого принимать решения о том, как будут выглядеть новые REST API методы.

В этой статье я хочу представить результаты исследований REST API сервисов управления задачами Trello и Todoist, чтобы показать, какие решения являются хорошими стандартами проектирования, а какие нет, но их всё равно применяют на практике.


👉 Решенные вопросы с обоснованием ответов:

1. Какой HTTP-код ответа на метод POST: 200 или 201?

2. Какой метод лучше использовать для редактирования данных: POST, PUT или PATCH?

3. Как правильно строить структуру URL запросов (эндпоинтов)?

4. Как правильно именовать эндпоинты — ед. число или мн. число (/task или /tasks)?

5. Как строить эндпоинт и body в REST API методе, если нам нужно создать задачу, и она должна быть создана внутри проекта?

6. Что вернуть в ответ на запрос списка, если ничего не найдено — пустой массив или HTTP-404?

7. Какой код вернуть в ответ на запрос DELETE?

8. Может ли быть у DELETE тело запроса?

9. Чем отличается REST от RESTful API?


🔗 Ссылка на статью


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

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

⚡️ Как выделять микросервисы? ⚡️

1️⃣ По группам функций
2️⃣ По доменам (Domain-driven Design, DDD)
3️⃣ По данным
4️⃣ По пользовательским сценариям
5️⃣ По уровню нагрузки

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

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

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

🧐 Как системный аналитик влияет на проектирование архитектуры 🧐

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

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

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

1. Исследования и анализ
2. Выбор подхода к проектированию архитектуры
3. Формирование концептуальной схемы архитектуры
4. Оценка влияния нефункциональных требований

🔗 Ссылка на статью

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

🔥 13 ошибок в использовании BPMN: разбор на примере задачи 🔥

В этом эпизоде подкаста мы разбираем 13 типичных ошибок при использовании нотации BPMN на примере задачи, которую может получить на собеседовании Системный или Бизнес-аналитик.

🔗 Презентация и полезные ссылки

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

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

Видео эпизода доступно в:
⏯ RuTube
⏯ YouTube
⏯ VK Video

Аудио-эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Spotify

Подписывайтесь на GetAnalyst, чтобы получать новые знания в системном анализе каждый день 🚀

🚀 Открытый урок по Архитектуре на этой неделе [1-3 марта] 🚀

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

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


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

💎 Проектирование архитектуры: от монолита к микросервисам
🗓 Доступ с 1 по 3 марта (сб-пн)
🔗 Зарегистрироваться

План:
1. Роль системного аналитика в проектировании архитектуры
2. Погружение в проект
3. Проектирование монолита
4. Переход к сервисной (SOA) и микросервисной (MSA) архитектуре
5. Проблемы при делении монолита на микросервисы
6. Базовые знания аналитика для работы с архитектурой


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

Регистрируйтесь, чтобы получить доступ к этому обучению!