Архитектура систем: вопросы для собеседования QA

В микросервисах основной риск — ошибки на стыках сервисов и рассинхрон данных.

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

Из практики: единичные сервисы часто «зелёные», а сценарий целиком ломается между ними.

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

Микросервисы — набор независимых сервисов с чёткими API-контрактами. Масштабируются и деплоятся независимо, но сложнее в тестировании: больше интеграционных точек, распределённые транзакции, сетевые сбои.

Из практики: переход от монолита к микросервисам обычно увеличивает количество интеграционных дефектов — важно заранее усилить контрактное и интеграционное тестирование.

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

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

Из практики: такие проверки заранее показывают слабые места, которые обычный регресс не ловит.

Тестирование микросервисов — это прежде всего проверка взаимодействия сервисов, а не каждого сервиса отдельно.

Я делаю упор на договоры, интеграционные сценарии и корректную обработку сбоев зависимостей.

Из практики: самые сложные дефекты почти всегда живут на стыках сервисов.

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

Модульный монолит — монолит с чёткими модулями, чьи границы соблюдены в коде. Сохраняет простоту деплоя, но даёт изолируемость. Лучший выбор для команд до 30–50 человек.

Микросервисы — много мелких независимых сервисов с собственными БД и релизами. Плюсы: независимые команды, разные технологии, точечное масштабирование. Минусы: распределённая сложность (сеть, согласованность, мониторинг), высокий порог входа.

SOA (Service-Oriented Architecture) — стиль, где система разбита на крупные сервисы, связанные через корпоративную шину (ESB), обычно по SOAP/WS-*. Сервисы реюзаются между приложениями.

Микросервисы — эволюция SOA. Сервисы мельче, у каждого своя БД, без ESB (общение через REST/gRPC/события), децентрализованное управление, независимый деплой.

Из практики: SOA — про переиспользование крупных сервисов в энтерпрайзе. Микросервисы — про скорость разработки и автономность команд.

API Gateway — единая точка входа для внешних клиентов в систему из множества сервисов. Скрывает внутреннюю топологию, выполняет авторизацию, rate limiting, кэширование, агрегацию, версионирование, преобразование протоколов.

Примеры: Kong, Envoy, AWS API Gateway, NGINX. В микросервисной архитектуре почти обязателен — иначе клиенты должны знать про каждый сервис.

Из практики: API Gateway легко превращается в «свалку логики». Бизнес-логика не должна жить в gateway — только cross-cutting (auth, throttling, маршрутизация).

Service Discovery — механизм, позволяющий сервисам находить друг друга в динамической среде, где IP/порт могут меняться. Сервисы регистрируются в реестре (Consul, Eureka, etcd), клиенты запрашивают актуальный список инстансов.

Два подхода: client-side discovery (клиент сам смотрит в реестр и выбирает), server-side (балансер делает это за клиента, как в k8s через Service).

Из практики: в Kubernetes service discovery встроен — отдельный реестр обычно не нужен. В legacy-окружениях актуальны Consul/Eureka.

Вертикальное (scale up) — увеличить ресурсы одного сервера (CPU, RAM, диск). Просто, но ограничено железом и обычно сопровождается даунтаймом.

Горизонтальное (scale out) — добавить новые инстансы и распределить нагрузку. Практически без ограничений, отказоустойчиво, но требует stateless-приложения, балансера и репликации данных.

Из практики: для cloud-native приложений по умолчанию выбирают horizontal. БД часто масштабируют вертикально + read-replica горизонтально, потому что распределённая запись сложна.

Load Balancer — компонент, распределяющий входящие запросы между несколькими инстансами приложения. Может работать на L4 (TCP/UDP) или L7 (HTTP).

Алгоритмы: round-robin (по очереди), least connections (на наименее загруженный), least response time, hash (по IP/токену для sticky), weighted (с учётом мощности). Примеры: NGINX, HAProxy, AWS ELB.

Из практики: round-robin прост, но не учитывает реальную нагрузку. Least connections лучше для разнородных запросов.

CDN (Content Delivery Network) — географически распределённая сеть кэширующих серверов. Контент (статика, медиа, иногда API-ответы) раздаётся клиенту с ближайшего узла, снижая latency и нагрузку на origin.

Используется для статики (JS/CSS/изображения), видео-стриминга, мобильных приложений. Примеры: Cloudflare, Akamai, AWS CloudFront, Fastly.

Из практики: правильно настроенный CDN ускоряет загрузку сайта в разы и снижает счёт за трафик. Главное — корректные Cache-Control.

Event-driven — стиль, где сервисы общаются через события: «что-то произошло». Один сервис публикует событие, другие подписываются и реагируют. Связанность по времени и по данным — слабая.

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

Из практики: эвент-дривен особенно подходит для аналитики, аудита, fan-out уведомлений. Не подходит, когда нужен синхронный ответ «сделано/не сделано».

Saga — паттерн управления длительной распределённой транзакцией через цепочку локальных транзакций в разных сервисах. Если шаг падает — выполняются компенсирующие действия для отката предыдущих шагов.

Два стиля: оркестрация (центральный оркестратор знает последовательность) и хореография (каждый сервис реагирует на события и публикует свои).

Из практики: классический пример — оформление заказа: резерв на складе → списание со счёта → создание доставки. Каждый шаг — своя транзакция, на ошибку — компенсация.

CQRS (Command Query Responsibility Segregation) — разделение моделей записи (command) и чтения (query). У записи свои таблицы/сервисы, у чтения — оптимизированные представления.

Event Sourcing — хранение состояния не как «текущего снимка», а как последовательности событий. Текущее состояние восстанавливается воспроизведением событий. Часто используется вместе с CQRS.

Из практики: оба паттерна оправданы там, где нужен полный аудит, сложная аналитика прошлого, многомодельное чтение. Это серьёзная инфраструктура — для типичных CRUD-приложений overkill.

На уровне архитектуры — это проектное свойство, что повторное получение того же сообщения или вызов того же endpoint не приводит к повторному эффекту. Реализуется через ключи идемпотентности, уникальные natural keys, проверку версий (optimistic locking), exactly-once-семантику обработки.

Нужна потому, что в распределённой системе ВСЕГДА бывают повторы: сетевые ошибки, retry клиентов, at-least-once гарантии очередей, переподписки потребителей.

Из практики: «спроектировать идемпотентность» = выбрать стратегию ключа и точку дедупликации (БД, кэш, business-logic). Без явного проектирования получим дубли.