Статья к эпизоду

Вопросы и ответы для подготовки к собеседованию на Senior Системного Аналитика

Оглавление:
1. Какие виды архитектуры вы знаете? В чем отличия?
1.1. Шаблоны проектирования микросервисной архитектуры
2. Подходы к интеграции сервисов в распределенных системах
3. Что такое API Gateway? Зачем нужен API Gateway? Преимущества и недостатки.
3.1. Является ли АПИ гейтвэй точкой отказа в системе?
4. Что такое хореография и оркестрация? В чем отличия? Расскажите на примерах
5. Какие способы управления высокой нагрузкой для систем вы знаете?
6. Задача на развязку “Многие-ко-многим” в БД
7. Миграция данных без простоя в продакшн: как реализовать?
8. Какие виды интеграции систем вы знаете?
9. Брокеры и очереди сообщений. RabbitMQ и Kafka.
10. Что такое аутентификация и авторизация в API? Как это работает?
Другие вопросы

1. Какие виды архитектуры вы знаете?

Монолитная архитектура
Все компоненты приложения находятся в одной кодовой базе и работают как единое целое.

БД:
Обычно одна, но допустимо и несколько.

Внутренние интеграции:
Компоненты взаимодействуют только на уровне кода, интеграции компонентов внутри Backend по API и другими способами НЕ нужны.

Ниже приведен пример схемы архитектуры для модульного монолита для Интернет-магазина.

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

БД:
Каждый сервис может использовать свою собственную БД.
Также несколько сервисов могут использовать одну общую БД - это отличает SOA от MSA.

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

Микросервисная архитектура, MSA
Состоит из множества маленьких, независимо разрабатываемых и развертываемых сервисов, каждый из которых выполняет определенную бизнес-логику. Микросервисы меньше по функциональности, чем сервисы. Подход эффективен для больших и быстро развивающихся приложений.

БД:
Каждый микросервис управляет своей собственной БД.

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

Event-Driven Architecture, EDA

Event-Driven Architecture — это архитектурный стиль, при котором взаимодействие компонентов строится на обмене событиями.

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

Важно понимать, что Event-Driven Architecture (EDA) — это независимый архитектурный стиль, а не просто "опция" внутри микросервисной архитектуры.

Выбор архитектуры проекта зависит от специфики и НФТ к системе.

На практике часто используют либо смесь подходов SOA и MSA, либо начинают проекты с монолита и через 3-5 лет задумываются о переезде на SOA в качестве первого этапа деления монолита на микросервисы.

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

1.1. Шаблоны проектирования микросервисной архитектуры

https://t.me/getanalysts/2451

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️⃣ Хореография 
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.

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

2. Подходы к интеграции сервисов в распределенных системах

Прямые вызовы по API

Сервисы взаимодействуют напрямую в формате запрос–ответ по протоколам HTTP/REST или gRPC.

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

API Gateway Internal

API Gateway выступает в роли единой точки входа, обеспечивающей маршрутизацию запросов, аутентификацию, авторизацию, трансформацию данных и реализацию кросс-сервисных политик.

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

Хореография (Event-Driven Architecture)

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

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

Оркестрация

Централизованный компонент (оркестратор) управляет выполнением бизнес-процесса, вызывая шаги и компенсации. Пример — паттерн саги с оркестратором.

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

ESB (Enterprise Service Bus)

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

Преимущества: поддержка множества протоколов и форматов; централизованное управление интеграциями.
Недостатки: риск превращения в «бутылочное горлышко»; высокая сложность сопровождения; избыточная связанность при чрезмерной логике в шине.

Дополнительно и допустимо, но не всегда оптимально:

3. Что такое API Gateway? Зачем нужен API Gateway? Преимущества и недостатки.

https://t.me/getanalysts/2445

API Gateway (API-шлюз) — это единая точка входа для всех клиентских запросов к Backend.

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

Его главная функция  — маршрутизация запросов.
Но, помимо этого, API Gateway предоставляет и другие важные функции.


Как работает:

1️⃣ Первичная обработка запроса
Клиент отправляет запрос в API Gateway, а не напрямую к сервисам. Это обеспечивает централизованную точку входа в систему, а также упрощает интеграцию для клиента.

2️⃣ Валидация запроса
API Gateway проверяет корректность запроса.
Если формат нарушен — запрос отклоняется.

3️⃣ Проверка безопасности
Выполняется проверка по спискам разрешённых (allow-list) и запрещённых (deny-list) источников. Небезопасные запросы блокируются.

4️⃣ Аутентификация и авторизация
Проверяет токены и другие учетные данные. Гарантирует, что у клиента есть необходимые разрешения для доступа к запрашиваемым ресурсам.

5️⃣ Ограничение частоты запросов (Rate Limiting)
Если клиент превышает лимит запросов — они отклоняются с соответствующим ответом.

6️⃣ Маршрутизация к нужному сервису
На основе пути или других признаков API-шлюз определяет, какому микросервису должен быть направлен запрос.

7️⃣ Преобразование протоколов
При необходимости, преобразует запрос в нужный формат.
Например, если API Gateway принимает запрос в HTTP (REST API), то он может преобразовать его в gRPC для внутреннего микросервиса.

8️⃣ Агрегация ответов
Если ответ зависит от нескольких микросервисов, API Gateway собирает данные с каждого и формирует единый ответ.

9️⃣ Возврат ответа клиенту
Сформированный ответ возвращается клиенту в нужном формате и в установленный тайм-ауты.

🔟 Логирование, мониторинг, обработка ошибок и кэширование
На протяжении всего процесса обработки запроса.


API Gateway упрощает взаимодействие клиентов с распределённой системой и обеспечивает её безопасную и управляемую работу, выступая в роли централизованной точки входа.

3.1. Является ли API Gateway точкой отказа в системе?

https://t.me/getanalysts/2452

Да — если он не масштабирован горизонтально.

Если на сервере развернут единственный инстанс (установленная копия) API Gateway и он выйдет из строя, работа всех клиентов, которые в него обращаются, остановится.

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


🚨 Что будет, если API Gateway «упадёт»?
1. Внешние клиенты потеряют доступ к сервисам.
2. Внутренние вызовы (если они идут через Gateway) тоже могут быть нарушены.
3. В логах вы увидите HTTP 502 / 503 ошибки (Bad Gateway / Service Unavailable).
4. Мониторинг начнёт фиксировать обрыв соединения и рост ошибок. Это будет сложно не заметить 🥲


👉 Как это решается?
Чтобы API Gateway не стал "узким горлышком", применяют следующие решения:

🟢 Горизонтальное масштабирование
Несколько инстансов API Gateway, развернутых за балансировщиком нагрузки. Тогда при сбое одного — остальные продолжают обслуживать запросы.

🟢 Health-check и авто-рестарт
Kubernetes и другие оркестраторы позволяют перезапускать поды/контейнеры при сбое.

🟢 Failover-механизмы
Некоторые решения "из коробки" поддерживают автоматическое переключение между инстансами при сбоях.

🟢 Разделение входящего трафика
В больших системах могут использовать несколько API Gateway по зонам или типам трафика (например, публичный API и внутренний API)


Несмотря на сбой API Gateway, внутренние сервисы продолжают жить, поэтому, если они не делают обратные вызовы в API Gateway для обращения в другие сервисы, то все начатые цепочки транзакций (запросов) будут выполнены.

Т.е. данные не теряются, процессы продолжаются.


API Gateway - потенциальная точка отказа в системе?
👉 Да

Но при нормальной инфраструктуре не должен быть ею. Мы разбираем это на программе по архитектуре. Это часть про стык Инфраструктуры и Архитектуры, который важно осознавать аналитикам.

4. Что такое хореография и оркестрация? В чем отличия? Расскажите на примерах?

https://t.me/getanalysts/2490

Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.

Пример оркестратора “из коробки”: Camunda.

Оркестратор вызывает нужные микросервисы по порядку (например: сначала — платёж, затем — бонусы, потом — уведомление) и отслеживает результат выполнения каждого этапа.

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

Пример сценария:

1. Клиент → API Gateway.
Покупатель жмёт «Оплатить».
Frontend отправляет запрос на API Gateway POST /payments.

2. API Gateway → Сервис платежей.
Проксирование запроса, проверка аутентификации/лимитов.

3. Сервис платежей → Оркестратор.
— Проводит списание средств у платежного провайдера (интеграция с внешней системой на схеме не показана.
— Пишет запись о платеже в свою БД.
— Перенаправляет процесс в обработку на Оркестратор для продолжения сценария оплаты.

4. Оркестратор → Сервис склада (Inventory).

Проверяет остатки и принимает решение о выполнении заказа:

5. Оркестратор → Сервис заказов

Обновление статуса на "Оплачен" или "Отменен", в зависимости от результата предыдущего шага.

6. Оркестратор → Сервис уведомлений.
Отправляет клиенту e-mail / push / SMS.

7,8,9. Возврат итогового результата на клиента.

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

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

Сервисы подписываются на события в брокере, такие как charging.finished («завершение зарядки»), payment.success («оплата проведена успешно»), и реагируют на них независимо друг от друга.

Синхронная часть процесса

1. Клиент → API Gateway.
Покупатель жмёт «Оплатить».
Frontend отправляет запрос на API Gateway POST /payments.

2. API Gateway → Сервис платежей.
Проксирование запроса, проверка аутентификации/лимитов.

3. Сервис платежей → Брокер.
— Авторизует/списывает платёж у провайдера, фиксирует результат в своей БД.
— Публикует событие в брокер: PaymentCaptured с payment_id, составом заказа, клиентом.

3.1. Сервис платежей → API Gateway.
Ответ 200 OK / 202 Accepted:

3.2. API Gateway → Клиент.
Ответ 200 OK / 202 Accepted:

Обработка события в брокере - хореография процесса

4.1. Сервис склада (подписчик).

Получает событие PaymentCaptured и пытается зарезервировать позиции.

4.2. Сервис заказов (подписчик).

5. Сервис уведомлений (подписчик).

5. Какие способы управления высокой нагрузкой для систем вы знаете?

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

1. Масштабирование

2. Кэширование

3. Балансировка нагрузки

4. Асинхронная обработка через брокеры сообщений

5. Ограничение скорости запросов (Rate Limiting)

Рекомендация: Нефункциональные требования: пример для медицинской системы

6. Задача на развязку “Многие-ко-многим” в БД

Подробный разбор вопроса в подкасте:
Связь "многие-ко-многим" в БД: разбор задачи с собеседования на системного аналитика

7. Миграция данных без простоя в продакшн: как реализовать?

• Внутри одной БД — выполнять изменения в несколько этапов: добавить новые структуры (поля, таблицы), заполнить их данными параллельно с текущими, постепенно перевести приложение на использование нового формата, затем удалить устаревшие элементы.
• Между разными СУБД — организовать перенос данных порциями (batch), синхронизировать изменения через механизмы CDC или репликации, и только после полной выравнивания данных переключить приложение на новый источник.

8. Какие виды интеграции систем вы знаете?

https://t.me/getanalysts/2522

1. Синхронные по API (REST, SOAP, GraphQL и другие)
2. Асинхронные по API (Webhook, Polling) - рекомендую подкаст "Что такое вебхуки и зачем они нужны: собеседование на системного аналитика по API и Webhooks" и статью к нему.
3. Режим реального времени (WebSocket, SSE и другие)
4. Брокеры и очереди сообщений
5. Общая БД
6. Обмен файлами

9. Брокеры и очереди сообщений. RabbitMQ и Kafka.

Разница между брокерами и очередями разбирается в статье "Брокер и очередь сообщений: что это и в чем отличия?"

Чтобы глубоко разобраться с темой брокеров рекомендую познакомиться с эпизодами подкаста про Kafka и RabbitMQ:

10. Что такое аутентификация и авторизация в API? Как это работает?

Рекомендуем подкаст:
Авторизация в API: что нужно знать системным аналитикам для работы с требованиями и собеседований

Дополнительно

Вопросы и ответы к собеседованию по REST API для системного аналитика:

Вопросы и ответы по REST API: собеседование на системного аналитика
Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)

Ещё эпизоды, которые могут вас заинтересовать