От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру

Читать статью | Analyst IT

Салют! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA, и затронем тему архитектуры ПО, тем более мы затрагивали целую неделю эту тему:

#вопросыссобеседования | @ba_and_sa

Часть 20:

📍Вопрос 1: Расскажите кратко, что такое архитектура ПО, и для чего ее нужно понимать аналитику?

✅Краткий ответ:

Архитектура ПО — это фундаментальная организация системы, воплощенная в виде ее компонентов, их взаимоотношений друг с другом и окружением, а также принципов, governing ее проектирование и эволюцию.

Для чего она аналитику?

1. Говорить с разработчиками на одном языке и формулировать требования, реализуемые в рамках существующих ограничений.

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

3. Выявлять архитектурно-значимые требования (масштабируемость, отказоустойчивость, безопасность), которые часто неочевидны для бизнеса, но vital для технического успеха проекта.

4. Проектировать интеграции между системами, понимая стили взаимодействия (REST, messaging, events) и их последствия.

Вместо итога: понимание архитектуры позволяет аналитику предлагать не просто корректные, но и реализуемые в рамках системы решения

📎Материалы по теме:
- Зачем системному аналитику читать «Чистую архитектуру» Роберта Мартина
- Роль системного аналитика при проектировании архитектурных решений

📍Вопрос 2: Как вы учитываете архитектуру системы при сборе требований и написании ТЗ?

✅ Краткий ответ:

Я рассматриваю архитектуру, как набор возможностей и ограничений. При работе с требованиями, я сначала изучаю текущую архитектуру через документацию и обсуждения с разработчиками.

Это помогает:

1. Предлагать реализуемые решения — предлагать функции, которые вписываются в текущую систему, а не требуют её перестройки.

2. Учитывать интеграции — правильно описывать взаимодействие компонентов, протоколы и форматы данных.

3. Выявлять скрытые сложности — например, понимать, что «простая» функция может потребовать изменений в нескольких микросервисах или создать нагрузку на базу данных.

В ТЗ выделяются архитектурно-значимые требования — производительность, безопасность, масштабируемость — чтобы разработка сразу закладывала их в реализацию

📍Вопрос 3: Какие технологии и паттерны вы бы использовали при проектировании системы для обработки большого объема транзакций в реальном времени с гарантией доставки и без потерь данных?

✅ Краткий ответ:

- Технологии: Kafka (для очередей), Apache Flink/Spark Streaming (для обработки), PostgreSQL (с репликацией) или Cassandra (для масштабируемости).

- Паттерны:
- CQRS (разделение на запись и чтение для масштабирования).
- Event Sourcing (хранение всех событий для восстановления состояния).
- Saga Pattern (для управления распределенными транзакциями).
- Гарантии доставки: подтверждение (ack) в Kafka, idempотентные операции, Dead Letter Queue (DLQ) для обработки ошибок.

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

📎Материалы по теме:
- Архитектурные паттерны
- Введение в Apache Kafka для системных аналитиков и проектировщиков интеграций

Источник: @ba_and_sa

‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования