Вопросы для контроля по проектированию архитектуры информационных систем

Вопрос 1. Теоретический вопрос

- Domain-Driven Design (DDD) – предметно-ориентированное проектирование. Раскройте основные принципы DDD: фокус на предметной области и бизнес-логике, использование Ubiquitous Language (единого языка) совместно с экспертом предметной области. Что такое сущности, значения (Value Objects), агрегаты, доменные события, репозитории в DDD, и как они облегчают поддержку сложной бизнес-логики.
- Observability (наблюдаемость) распределенных систем. (с докладов) Раскройте понятие наблюдаемости: возможности системы обеспечивать сбор телеметрии, необходимой для анализа работы. Три столпа observability – логи, метрики, трассировки: объясните, что каждый из них дает архитектору и инженеру эксплуатации. Почему в микросервисной архитектуре наблюдаемость особенно важна (сложнее отладить поток запросов): упомяните корреляцию логов по trace-id, распределенные трейсинг-системы (Jaeger, Zipkin) и метрики (Prometheus/Grafana).
- RESTful-архитектура и принцип идемпотентности. Опишите принципы REST: представление ресурсов через URL, использование стандартных HTTP-методов (GET, POST, PUT, DELETE, etc.), отсутствие состояния на сервере между запросами (stateless). Раскройте понятия безопасности методов (safe methods) и идемпотентности методов: какие HTTP-методы должны быть идемпотентны (GET, PUT, DELETE) и почему это важно для надежности веб-сервисов. Приведите пример корректного использования идемпотентности (например, повторный PUT обновления ресурса не изменяет систему после первого применения).
- Архитектура корпоративных систем (ERP, CRM, BI, BPM-системы) и особености их проектирования. Объясните, что такое ERP и CRM системы, какую роль они играют в бизнесе. Особенности их архитектуры: модульность, настраиваемость (конфигурирование под бизнес-процессы), интеграция множества подсистем (управление финансами, складом, продажами – для ERP; управление взаимоотношениями с клиентами – для CRM). Упомяните архитектуру BPM-систем (системы управления бизнес-процессами) – как они позволяют графически моделировать процессы и исполнять их, и как архитектурно реализованы (движок процессов плюс интеграционные коннекторы).
- Архитектурные стили: понятие и классификация. Объясните, что такое архитектурный стиль системы и чем он отличается от паттерна проектирования. Приведите примеры распространенных стилей (слоистый, клиент-сервер, микросервисный, событийно-ориентированный, MVC и др.) и кратко укажите, для каких ситуаций каждый подходит.
- Виды архитектур и уровни архитектурных решений в информационных системах. Раскройте различия между уровнями архитектуры: корпоративная архитектура, архитектура решения (системы), программная (приложения) и техническая (инфраструктуры). Как они взаимосвязаны и какие задачи решаются на каждом уровне.
- Документация архитектуры: представления и коммуникация. Объясните, зачем нужен архитектурный документ и различные представления системы (viewpoints). Какие виды представлений обычно описывает архитектор: логическое (структура модулей), физическое (развертывание на узлах), вид процессов (взаимодействие/потоки данных), вид развития (как внедряются изменения). Кратко коснитесь модели 4+1 (логический, разработческий, процессный, физический представления + сценарии) и важности поддержания документации в актуальном состоянии.
- Документирование архитектуры: модель C4 и другие нотации. Объясните, что такое C4-модель (Context, Container, Component, Code) и как она используется для представления системы на разных уровнях абстракции. Какие типы диаграмм используются на каждом уровне (контекстная диаграмма системы, контейнерная диаграмма, компонентная диаграмма, диаграмма кода) и какую информацию они передают. Кратко упомяните и другие нотации архитектурного описания – UML, ArchiMate – и их роль.
- Жизненный цикл разработки информационной системы и роль архитектуры на каждой стадии (инициация, анализ требований, проектирование, реализация, внедрение и сопровождение). Как архитектор участвует на этапах и какие решения принимает.
- Интеграция информационных систем: методы и подходы. Рассмотрите способы взаимодействия разнородных систем: синхронные (прямые API-вызовы, SOAP/REST-сервисы) и асинхронные (обмен сообщениями через очереди, топики). Что такое посредники интеграции – шина данных (ESB), брокеры сообщений – и когда их имеет смысл использовать. Объясните понятие согласованности данных при интеграции: локальные транзакции vs. распределенные, паттерн «Вечная сага» (Saga) для обеспечения целостности бизнес-процесса без глобальной транзакции.
- Инфраструктура и DevOps в контексте архитектуры. (с докладов) Объясните, как современные подходы DevOps влияют на архитектуру: контейнеризация (Docker) позволяет унифицировать окружение запуска, оркестрация (Kubernetes) – управлять кластером микросервисов, Infrastructure as Code – поддерживать конфигурацию среды в виде кода. Расскажите о практике CI/CD: как конвейер непрерывной интеграции и доставки (сборка, тестирование, деплой) требует модульной архитектуры и автоматизации. Почему архитектору важно учитывать деплоймент-процесс при проектировании (например, разделение на микро-сервисы должно сопровождаться средствами их автоматического развертывания и мониторинга).
- Масштабирование информационных систем: вертикальное и горизонтальное. Объясните разницу между вертикальным масштабированием (увеличение ресурсов одного сервера – более мощный CPU, RAM) и горизонтальным (добавление большего числа узлов/серверов). В каких ситуациях применим каждый подход и как выбор влияет на архитектуру (например, горизонтальное масштабирование требует распределения нагрузки – load balancing, стейтлесс-сервисы). Упомяните концепцию эластичности в облаке (авто-масштабирование) и масштабирование баз данных (репликация для чтения, шардирование).
- Микросервисная и монолитная архитектуры: сравнение подходов. Опишите ключевые характеристики монолита и микросервисов, их достоинства и недостатки. Вопрос охватывает масштабируемость (микросервисы позволяют масштабировать отдельные компоненты), независимость развертывания, сложность управления (оркестрация, Discovery) и требования к инфраструктуре. Особо укажите, почему микросервисы требуют решений для межсервисной коммуникации, согласованности данных и обратной совместимости (при эволюции API микросервисов).
- Надежность vs. консистентность: модели транзакций ACID и BASE. Объясните, что такое ACID-транзакции в классических монолитных системах (атомарность, согласованность, изолированность, долговечность) и почему они важны для гарантированной целостности данных. Затем опишите альтернативный подход для распределенных систем – BASE (Basically Available, Soft state, Eventual consistency): отказ от жесткой мгновенной консистентности ради доступности и масштабируемости, eventual consistency (постепенное достижение согласованности). В каких случаях архитектор может предпочесть BASE-модель (например, в геораспределенных системах или больших нагрузках, когда CAP-теорема диктует выбор AP-системы).
- Надежность и отказоустойчивость в архитектуре информационных систем. Объясните, за счет чего достигается надежность системы: резервирование компонентов (кластеризация серверов приложений, репликация баз данных), устранение единой точки отказа, механизмы отказоустойчивости (фейловер, автоматический рестарт). Упомяните CAP-теорему в контексте надежности распределенных систем: почему одновременно достичь консистентности и доступности при разделении сети невозможно, и как системы выбирают компромисс (AP или CP).
- Паттерн CQRS (Command Query Responsibility Segregation). Объясните принцип разделения операций чтения и записи в разных моделях. Как работает CQRS, в чем его преимущества при масштабировании нагрузок на чтение или запись, и какие сложности он привносит (синхронизация данных, eventual consistency). Приведите пример, когда применение CQRS обосновано, например в сочетании с Event Sourcing для сложных доменов.
- Паттерны проектирования и их роль в архитектуре. (с докладов) Объясните, как шаблоны проектирования GoF (Factory, Singleton, Adapter, Observer и др.) и архитектурные паттерны используются на практике для решения типовых задач. Приведите по одному примеру: как Factory помогает управлять созданием сложных объектов, Singleton обеспечивает глобальный доступ к ресурсу, Adapter позволяет согласовать несовместимые интерфейсы, Observer обеспечивает реагирование на события. Укажите, почему знание паттернов важно архитектору – для коммуникации и быстрого прототипирования решений.
- Сервис-ориентированная архитектура (SOA) и ее место в эволюции архитектур. Рассмотрите принципы SOA: разделение на относительно крупные сервисы, повторное использование функциональных модулей, коммуникация через сервисную шину (ESB) или сообщения. Как SOA решает проблему дублирования функций в корпоративных системах. Сравните SOA с микросервисами: границы сервисов, управление сообщениями, требования к согласованности.
- Системное мышление и холистический подход в архитектуре. Объясните, что подразумевается под системным мышлением архитектора: умение видеть систему целиком, учитывая связи между компонентами, влияние окружения, ограничения и потребности стейкхолдеров. Как системное мышление помогает при принятии архитектурных решений (балансировать требования, находить компромисс между скоростью разработки и долговременной поддержкой, прогнозировать влияние изменений). Приведите пример: внедрение нового модуля в систему – архитектор оценивает, как это скажется на других модулях, данных, инфраструктуре и процессе разработки.
- Требования к информационным системам и их влияние на архитектуру. Классификация требований на функциональные и нефункциональные, примеры каждого вида. Как архитектор выявляет и учитывает нефункциональные требования (производительность, масштабируемость, безопасность, надежность и др.) при проектировании системы.
- Тренды в архитектуре информационных систем: контейнеры, облачные сервисы, бессерверные вычисления. (с докладов) Объясните, как облачные платформы изменили подход к архитектуре: возможность использовать Serverless-компьютинг (функции как сервис, AWS Lambda и аналоги) для событийных задач, микросервисы в облаке с автоматическим масштабированием, управляемые базы данных и очереди. Опишите идею Function-as-a-Service: разработчик пишет функцию, которая выполняется в облаке по событию, и не управляет серверами. В чем плюсы Serverless (масштабирование по вызову, оплата за фактическое время работы) и какие ограничения (холодный старт, ограниченное время выполнения, сложность состояния).
- Эволюция архитектуры и системное наследование. (с докладов) Объясните, как развивается архитектура по мере роста системы: от простого монолита к модулярному монолиту, затем к микросервисам, возможно к облачным нативным решениям. Затроньте понятие технического долга: почему со временем архитектура может требовать рефакторинга или переработки, и как управлять эволюцией (например, стратегия Strangler Fig при постепенном выносе модулей монолита в сервисы). Упомяните, как учитывать наследованные (legacy) системы: использование анти-коррупционных слоев, постепенная модернизация.


Вопрос 2. Вопросы по паттернам:
-  Adapter (Адаптер). Опишите суть паттерна Адаптер: необходимость «обернуть» один интерфейс в другой для совместимости. Приведите пример интеграции: когда новая система должна использовать функциональность старой через несовместимый интерфейс – пишется адаптер, переводящий вызовы. Укажите, что адаптеры широко применяются при интеграции библиотек, работе с legacy-кодом или внешними API.
-  Circuit Breaker («автоматический предохранитель»). Опишите данный паттерн устойчивости: как компонент-предохранитель отслеживает вызовы к внешнему сервису и при многочисленных сбоях «размыкает цепь», временно прекращая попытки достучаться до сбойного сервиса. Объясните, как Circuit Breaker помогает системе оставаться работоспособной (предотвращает истощение ресурсов ожиданием недоступного сервиса) и что происходит после таймаута (паттерн Half-Open для проверки восстановления).
-  Hexagonal Architecture (гексагональная, «Ports and Adapters»). Опишите суть гексагональной архитектуры: разделение ядра приложения (домена) и внешних служб через порты и адаптеры. Как этот паттерн обеспечивает независимость бизнес-логики от деталей реализации (UI, БД, внешние API) и упрощает тестирование.
-  MVC (Model–View–Controller). Опишите данный паттерн проектирования: какую роль выполняют Model, View и Controller, как они взаимодействуют между собой. Приведите пример применения MVC в веб-приложениях и объясните, как разделение на MVC способствует поддерживаемости кода.
-  MVVM (Model–View–ViewModel). Опишите данный паттерн, используемый чаще всего в клиентских приложениях. Как ViewModel отделяет логику представления от UI и двустороннее связывание данных. В каких случаях MVVM предпочтительнее, чем MVC (например, в десктопных или мобильных приложениях), и как упрощает тестирование интерфейса.
-  Observer (Наблюдатель) – шаблон проектирования. Опишите механизм паттерна Observer: объект-издатель при изменении своего состояния рассылает уведомления подписанным объектам-наблюдателям. Где применяется Observer (например, в GUI фреймворках – подписка на события UI, в Event Sourcing – подписчики на события). Укажите отличие событийной модели (pub/sub через брокер) от паттерна Observer в коде – концептуально схожи (есть издатель и потребители), но реализации различны (локально в памяти vs. через посредника).
-  Proxy (Прокси) – структурный паттерн. Опишите назначение паттерна Proxy: предоставление суррогатного объекта-заместителя, который контролирует доступ к другому объекту. Варианты прокси: удаленный прокси (для обращения к удаленному сервису как к локальному объекту), виртуальный прокси (ленивая инициализация), защитный прокси (контроль доступа). Как Proxy используется, например, в ORМ (ленивое загрузка сущностей) или при вызове удаленных сервисов (gRPC генерирует прокси-объекты).
-  Service-Oriented Architecture (SOA). Дайте определение SOA: принцип организации системы в виде повторно используемых сервисов, взаимодействующих через четко определенные интерфейсы (часто через шину сервисов или сообщения). Укажите отличия SOA от микросервисной архитектуры (размер сервисов, степень распределенности, использование ESB) и типичные примеры SOA в корпоративных приложениях.
-  Внедрение зависимостей (Dependency Injection) – принцип и паттерн. Объясните, в чем состоит принцип DI: объекты не сами создают свои зависимости, а получают их извне (например, через конструктор, сеттер или контейнер). Как DI способствует слабой связности и облегчает тестирование. Приведите пример: использование IoC-контейнера (например, Spring) для внедрения реализации интерфейса службы.
-  Доменное событие (Domain Event) – паттерн в DDD. Объясните, что такое доменное событие: значимое событие, происходящее в предметной области, которое модель explicitly фиксирует. Как доменные события используются для связи между агрегатами внутри одного ограниченного контекста или для интеграции контекстов, и почему важна неизменяемость и описание события на языке домена. Укажите, как Domain Event соотносится с шаблоном Observer (по сути, является его специализированным случаем в бизнес-логике).
-  Клиент–серверная архитектура. Опишите принцип разделения на клиентскую и серверную часть, взаимодействие между ними по протоколу, а также преимущества и ограничения модели «клиент–сервер» в сравнении с одноуровневыми системами.
-  Микросервисная архитектура. Раскройте этот архитектурный паттерн: принципы построения системы как набора мелких автономных сервисов, взаимодействующих по легковесным протоколам. Перечислите ключевые паттерны внутри микросервисного стиля (например, API Gateway, Service Discovery, Circuit Breaker) и поясните, как микросервисы достигают гибкости и устойчивости к отказам.
-  Монолитная архитектура. Дайте характеристику монолитного стиля: единое развертываемое приложение, совместное размещение модулей. Опишите плюсы (простота разработки и деплоя, целостность) и минусы (низкая гибкость масштабирования, сложность поддержки большого кода) монолита, особенно в сравнении с микросервисами.
-  Ограниченный контекст (Bounded Context) – стратегический паттерн DDD. Объясните, что означает «ограниченный контекст»: самостоятельная часть доменной модели с собственным языком и моделями, четко отделенная от других контекстов. Как контексты взаимодействуют (через явно определенные контракты или анти-коррупционные слои) и почему этот паттерн важен для масштабирования разработки больших систем.
-  Репозиторий (Repository) – паттерн доступа к данным в DDD. Объясните назначение репозитория: предоставлять уровень абстракции между доменной логикой и инфраструктурой хранения. Как репозиторий имитирует коллекцию объектов в памяти, позволяя доменному коду не зависеть от деталей БД. Упомяните, чем репозиторий отличается от DAO, и как он вписывается в слоистую архитектуру (уровень инфраструктуры).
-  Сага (Saga) – паттерн управления транзакцией в микросервисной архитектуре. Опишите, как работает Saga: разбиение долгой распределенной транзакции на последовательность локальных операций с компенсациями при неудаче. Различайте оркестрацию саги (централизованный координатор) и хореографию (сами сервисы обмениваются событиями). Объясните, почему Saga обеспечивает целостность данных без использования двухфазного коммита, и приведите пример (например, бронирование поездки с отдельными сервисами билетов и оплаты).
-  Слоистая архитектура (многоуровневая архитектура). Опишите суть паттерна и типичные слои (например, презентационный, прикладной, уровень данных), а также преимущества такого разделения.
-  Событийно-ориентированная архитектура (Event-Driven Architecture, EDA). Опишите данный архитектурный стиль: как компоненты системы взаимодействуют через обмен событий (асинхронные сообщения). Приведите примеры шаблонов EDA: Publish/Subscribe (издатель-подписчик), Event Streaming. Объясните преимущества EDA (слабая связанность, масштабируемость в обработке событий) и сложные моменты (гарантия доставки, порядок событий).
-  Фабрика (Factory) – порождающий паттерн. Опишите различие между простым фабричным методом и абстрактной фабрикой. Зачем используются фабрики в архитектуре: например, чтобы отделить логику создания объектов от места их использования (особенно полезно при смене конкретных классов, тестировании, внедрении зависимостей).
-  Фасад (Facade). Опишите паттерн Фасад: предоставление простой унифицированной интерфейса к сложной подсистеме. Приведите пример использования фасада в архитектуре – например, API Gateway в микросервисах выступает фасадом для множества внутренних сервисов, скрывая их детали от внешних клиентов. Расскажите, как фасад улучшает модульность (внешние модули не зависят от деталей реализации подсистемы) и облегчает изменение подсистемы без затрагивания остального кода.
-  Чистая архитектура (Clean Architecture). Кратко опишите концепцию «Чистой архитектуры» Роберта Мартина: разделение системы на слои (entities, use cases, interface adapters, frameworks) с правилом зависимостей (источники зависимостей только внутрь). Как Clean Architecture схожа с DDD и гексагональной архитектурой (централизация бизнес-логики, независимость от технологий) и зачем она применяется.
-  Шаблон «Версионность API» в микросервисах (Backward Compatibility). Опишите, какие подходы используются для управления версиями API: версионирование URL или эндпоинтов (v1, v2 в пути), поддержка нескольких версий одновременно, практики deprecated и совместимости. Почему совместимость важна: чтобы клиенты сервисов продолжали работать при обновлении. Приведите примеры, как правильно внести изменения в контракт сервиса, не сломав старых клиентов (например, добавить новое поле – сделать его необязательным; для удаления поля – сначала объявить устаревшим, потом убрать в следующей мажорной версии API).



Вопрос 3. Практическое задание (будет указано это задание и ниже аналогичное дополнение с нюансом или на другом примере)

- Вы архитектор фотохостинга (сервиса, где пользователи загружают и хранят изображения). Предложите, как можно реализовать обработку загружаемых изображений в архитектуре Serverless. Например: при загрузке файла изображение сохраняется в облачное хранилище, генерируется событие (например, появление объекта в S3-бакете), которое триггерит безсерверную функцию (AWS Lambda или аналог) для создания превью-версии изображения. Готовые превью сохраняются обратно в хранилище, а пользователь уведомляется о завершении обработки. Опишите компоненты этого решения и взаимодействие между ними.
- Выделите границы ограниченных контекстов (Bounded Contexts) в предметной области онлайн-маркетплейса. В описании: маркетплейс включает каталóg товаров, управление заказами, платежный сервис, систему отзывов и поддержку клиентов. Разделите эту сферу на контексты (например, «Каталог и товарная информация», «Заказы и оформление», «Платежи», «Отзывы» и т.п.), кратко пояснив, почему они обособлены друг от друга.
- Для заданного сценария – небольшого веб-форума для сообщества – выберите архитектурный стиль реализации. Обоснуйте, стоит ли реализовать систему как монолитное приложение или сразу выделить микросервисы. Учитывайте масштабы (небольшая аудитория, ограниченные ресурсы разработки) и требования к развитию функциональности.
- На основе описания предметной области системы бронирования отелей определите ключевые сущности и агрегаты. Например, рассмотрите субдомен «Бронирование номеров»: выделите сущность Бронь (Booking) как агрегат и перечислите связанные с ней Value Object’ы (например, период проживания, данные гостя) и другие сущности в агрегате (номер комнаты, отель). Опишите границы ответственности этого агрегата.
- Нарисуйте контекстную C4-диаграмму для системы проката автомобилей. Отразите на ней основной сервис проката (как центральную систему) и внешних акторов: клиента-пользователя приложения, менеджера филиала проката, а также внешние системы – платежный сервис и сервис проверки водительских удостоверений. Подпишите связи между системой и этими внешними компонентами.
- Нарисуйте схему развертывания (deployment diagram) для веб-приложения средней нагрузки. Сценарий: веб-приложение состоит из фронтенд-сервера (React-приложение, которое может быть размещено на CDN), сервер приложений (backend API) и базы данных. Отобразите на схеме: пользовательский браузер обращается к фронтенд-серверу (или CDN) -> фронтенд обращается к серверу приложений (развернутому, скажем, на двух экземплярах для отказоустойчивости) -> сервер приложений подключается к кластеру базы данных (master-slave реплика). Укажите также балансировщик нагрузки перед серверами приложений.
- Нарисуйте схему уровневой (слоистой) архитектуры для системы интернет-банка. Укажите слои: представление (web-интерфейс, мобильное приложение), прикладной слой (бизнес-логика интернет-банкинга – операции со счетами, переводы, управление продуктами), уровень доступа к данным (сервер БД, хранилище транзакций). На схеме отобразите, какие основные компоненты находятся на каждом слое (например, на уровне представления – веб-сервер или фронтенд-приложение; на бизнес-слое – сервисы «Счета», «Платежи»; на уровне данных – СУБД, возможно кэш). Стрелками покажите взаимодействие: пользовательский запрос проходит через слой представления к бизнес-слою, который обращается к базе.
- Опишите стратегию масштабирования для новой социальной сети, которая выросла с 1000 до 1 000 000 активных пользователей. Предложите конкретные меры: горизонтальное масштабирование веб-серверов (добавление серверов приложений за балансировщиком нагрузки), вынос базы данных на кластер с репликацией, использование CDN для раздачи статического контента, внедрение кэширования часто запрашиваемых данных в памяти. Объясните, как эти изменения позволят системе выдержать рост нагрузки.
- Опишите стратегию управления версиями API для микросервиса профилей пользователей. Ситуация: текущая версия API (v1) предоставляет ресурс /api/v1/profile с определенным набором полей. Планируется изменить формат данных профиля (например, объединить поля имени и фамилии в одно). Предложите: выпустить новую версию API (v2) с измененным контрактом, сохраняя старую (/api/v1/profile) доступной в течение переходного периода; пометить в документации поле как устаревающее; обеспечить обратную совместимость на период миграции. Кратко опишите шаги перехода для клиентов на новую версию.
- Опишите, как обеспечить согласованность данных между двумя микросервисами в системе бронирования билетов. Сценарий: один сервис отвечает за резервирование места на мероприятии, другой – за оплату бронирования. Предложите подход, при котором при неудаче оплаты бронь отменяется. Например, распишите упрощенную последовательность шагов сага-паттерна: (1) Сервис бронирования создает бронь и публикует событие «Бронь создана» → (2) Сервис оплаты принимает событие и пытается провести платеж → (3) при успехе оплаты – публикуется событие «Оплачено», при неуспехе – событие «Платеж отклонен» → (4) Сервис бронирования слушает событие «Платеж отклонен» и снимает бронь.
- Перечислите ключевые нефункциональные требования для системы интернет-банкинга (онлайн-банка) и укажите метрики или критерии для их оценки. Например: безопасность - двухфакторная аутентификация, шифрование TLS для всех данных; доступность - 99.95% времени безотказной работы в год; производительность - поддержка 1000 транзакций в минуту с временем отклика не более 1 секунда в 95% запросов; масштабируемость - возможность горизонтального увеличения числа серверов при росте числа пользователей.
- Перечислите, какие ключевые показатели и журналы логов вы бы настроили для отслеживания работы микросервисного приложения по заказу такси. Укажите хотя бы: бизнес-метрики (число новых заказов в час, среднее время подачи машины), технические метрики (нагрузка CPU и памяти на сервисах, время отклика каждого сервиса, количество ошибок 5xx), логи (отдельные логи для важных действий: создание заказа, расчёт цены; логирование ошибок с стектрейсами), трассировка (прослеживание цепочки запросов через сервисы «Профиль пользователя», «Заказы», «Платежи» с единым trace-id). Объясните, как эти данные помогут выявить и диагностировать проблему (например, увеличение времени отклика конкретного сервиса).
- Постройте BPMN-диаграмму бизнес-процесса оформления заказа в интернет-магазине. Процесс: покупатель оформляет заказ на сайте → система проверяет наличие товаров на складе → осуществляется оплата → при успехе оплаты генерируется заказ на сборку и доставка. Отразите события начала и конца процесса, основные задачи (например, «Проверка наличия на складе», «Списание средств с карты») и переходы, включая разветвление по результату оплаты (успех или неуспех).
- Постройте диаграмму последовательности для сценария оформления заказа в интернет-магазине, показывающую взаимодействие компонентов системы. Участники: Пользователь (инициирует заказ на фронтенде), Веб-сервер/Frontend (например, SPA или мобильное приложение, отсылающее запрос на бэкенд), Сервис заказа (back-end, обрабатывающий заказ), База данных (хранит информацию о заказах), Внешний платежный сервис. Отразите на диаграмме: пользователь отправляет запрос на оформление → фронтенд отправляет запрос сервису заказа → сервис заказа создает запись заказа в БД, запрашивает платеж через внешний сервис → внешний сервис возвращает статус → сервис заказа обновляет статус заказа и возвращает ответ пользователю.
- Предложите меры для обеспечения высокой доступности (High Availability) в системе электронных платежей, которая должна работать 24/7. Например: реализовать отказоустойчивый кластер приложений на двух датацентрах (Active-Active или Active-Passive), использовать отказоустойчивый кластер СУБД или репликацию базы данных (master-slave с автоматическим переключением), внедрить мониторинг и автоматическое переключение (failover) при сбое узла. Опишите, как каждая мера убирает потенциальную «единую точку отказа» в системе.
- Предложите список функциональных и нефункциональных требований для системы интернет-магазина (online-ретейл) на основе описания бизнес-потребностей. Укажите ключевые функции (каталог товаров, корзина, заказ) и минимум три важных нефункциональных требования (например, производительность - время отклика до 2 секунд при 100 одновременных пользователях, безопасность данных пользователей и др.).
- Предложите способ интеграции между двумя подсистемами: веб-приложением заказа еды и системой ресторанов. Сценарий: пользователь делает заказ через приложение, а ресторан должен получить информацию о заказе. Выберите подход интеграции - например, через прямой REST API вызов ресторанного сервера или через брокер сообщений (очередь) - и обоснуйте, почему он подходит (учтите требуемую скорость передачи данных, надежность доставки, возможное время автономной работы ресторана).
- Предложите технологический стек для стартапа, создающего мобильное приложение обмена сообщениями (аналог мессенджера). Укажите выбор основных технологий: язык и фреймворк на серверной стороне (например, Node.js с Nest.js или Java с Spring Boot), тип базы данных (NoSQL для хранения сообщений и пользовательских данных, например MongoDB, для масштабируемости горизонтальной), протокол обмена сообщениями в реальном времени (WebSocket), облачную платформу для развертывания (например, AWS или другой с возможностью авто-масштабирования). Кратко обоснуйте каждый выбор с точки зрения требований стартапа (высокая нагрузка сообщений, необходимость быстрого развития).
- Представьте, что перед вами задача оптимизировать производительность новостного веб-сайта при высокой нагрузке на чтение. Предложите конкретное решение: внедрение многоуровневого кеширования. Например: кеширование на стороне браузера (HTTP-заголовки для статики), кеш на CDN для изображений и статических файлов, кеширование страниц или фрагментов на сервере (в памяти, Redis) для часто читаемых новостей, оптимизация запросов к БД (индексы, denormalization для горячих данных). Объясните, как каждое изменение сократит время отклика при большом числе одновременных читателей.
- Разбейте монолитную CRM-систему на микросервисы. Исходная монолитная система обслуживает отделы: продажи, маркетинг, поддержка клиентов - с общей базой данных. Предложите выделить три соответствующих микросервиса: Сервис Продаж, Сервис Маркетинга, Сервис Поддержки, каждому дать свою базу данных. Опишите, какие функции перейдут в каждый сервис (например, Сервис Продаж - управление сделками и клиентами, Маркетинг - рассылки и лиды, Поддержка - обращения клиентов и тикеты) и как данные, ранее соединенные в одной БД, будут разделены или дублироваться частично (например, справочник клиентов может реплицироваться между сервисами).
- Спланируйте непрерывную интеграцию и доставку (CI/CD) для веб-приложения. Опишите этапы конвейера: CI - разработчики пушат код в репозиторий → автоматический запуск сборки проекта (например, с помощью Maven/NPM) → прогон модульных и интеграционных тестов → сборка артефакта (контейнера Docker); затем CD - развёртывание нового образа на staging-среде, выполнение smoke-тестов → автоматическое развертывание на production при успешных тестах. Укажите инструменты, которые могли бы использоваться (например, Jenkins или GitLab CI для автоматизации, Docker Registry для хранения образов, Kubernetes для деплоя).
- Спроектируйте RESTful API для сервиса управления задачами (task-tracker, аналог Trello). Необходимо уметь: создавать новую задачу, получать список задач, изменять статус задачи, удалять задачу. Укажите ресурсные URL и соответствующие HTTP-методы для каждого действия. Отметьте, какие из этих операций должны быть идемпотентными (например, повторный DELETE на ту же задачу или PUT для обновления статуса не изменят результат после первого выполнения).