☀Объяснение:

Почему партиционирование не решает
Партиционирование по дате уменьшит объём сканирования, если в WHERE есть дата, но здесь её нет – придётся сканировать все партиции.

Материализованное представление (MV)

MV хранит предрассчитанный результат запроса: SELECT client_id, SUM(amount) as total FROM orders GROUP BY client_id.
Занимает места ~ (кол-во клиентов) × (несколько байт).
Обновляется инкрементально после каждого изменения в orders или по расписанию.
Запрос к MV вместо основной таблицы выполняется за миллисекунды (читает всего N строк).

В требованиях нужно указать:

«Для отчёта "топ клиентов" использовать материализованное представление client_totals».
«Обновлять представление раз в час (допустима задержка)».
«При изменении данных (INSERT/UPDATE) в orders запускать фоновую задачу пересчёта».

Реальный пример
В CRM-системе отчёт «крупнейшие покупатели» грузился 30 секунд. После создания MV с ежечасным обновлением время упало до 0.2 секунды.

☀Объяснение:

Почему сложность – главная проблема
Микросервисы решают проблемы масштаба (тысячи разработчиков, миллионы запросов). Для маленькой команды они вводят накладные расходы:
Настройка Kubernetes, сервис-меша, дата-центра или кластера.
Отладка распределённых транзакций – запрос идёт через 5 сервисов, ошибку трудно воспроизвести.
Развёртывание: нужно вызывать CI/CD для каждого сервиса (минимум 3–4).
Мониторинг и логи – собирать их с нескольких сервисов сложнее.
При 100 запросах/сек и 5 разработчиках монолит с чёткими модулями будет работать не хуже, а разработка пойдёт быстрее.

Что делать вместо?

Модульный монолит с чёткими границами пакетов. Если в будущем нагрузка вырастет до 1000+ запросов/сек, легко выделить узкие места в отдельные сервисы.

Реальные примеры

Instagram долгое время был монолитом на Django.
Twitter начинал с монолита Ruby on Rails, а микросервисы внедрял, когда столкнулся с миллионами запросов.

Что аналитик должен рекомендовать

Оценить масштаб (100 запросов/сек – смешная нагрузка для современного сервера).
Оценить команду (5 человек – не нужно разделять).
Указать в NFR не «микросервисы», а «архитектура должна позволять горизонтальное масштабирование и выделение сервисов при росте нагрузки».

Вывод
Не усложняйте. Самая быстрая архитектура для малой команды – монолит с чистыми интерфейсами.

☀Объяснение:

Реальность
Изменения требований в середине спринта — норма. Бизнес не обязан ждать. Но нельзя их принимать без анализа.

Правильный процесс

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

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

A – хаос, потеря контроля, срыв сроков.
C – негибкость, потеря доверия.
D – архитектор не владеет приоритетами бизнеса.

Реальный пример

В крупном ретейле заказчик попросил добавить отчёт по магазинам за прошлый месяц. Оценка показала 3 дня. Вместо срыва спринта договорились перенести менее важную фичу. Изменение задокументировали.

☀Объяснение:

Почему дублируется
Партнёр может скопировать файл повторно с тем же именем (по ошибке). Система видит новый файл и обрабатывает повторно, что ведёт к дублированию заказов.

Решение – идемпотентность на уровне файлов
Нужно хранить уже обработанные имена файлов и их даты модификации (или контрольные суммы). Например: таблица processed_files с колонками filename, size, modified_time, processed_at. Перед обработкой проверять, есть ли уже запись с таким именем и размером. Если есть — пропустить.
Дополнительно
Можно использовать .done файл (пустышка), который партнёр создаёт после окончания записи, и система ждёт наличия .done.
Или переименовывать обработки файл в .processed и не сканировать «старые» имена.
Почему не подходят другие

A (переименовывать) – но партнёр может положить файл заново уже с новым именем? Не решает глобально.
C (удалять) – плохо для аудита и отказоустойчивости.
D (ручная обработка) – не масштабируется.

Реальный кейс

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

☀Объяснение:

Проблема

Если в БД хранить время без зоны (timestamp), то каждый клиент интерпретирует его по своему часовому поясу (или вообще неверно). Решение: хранить все времена в UTC (единая глобальная шкала). При показе: брать временную зону пользователя (из профиля, геолокации) и преобразовывать.

Почему B оптимально

Универсальность: данные внутри системы всегда согласованы.
Миграция: если текущие записи трактовались как местное время (например, московское), нужно точно знать, в какой зоне они были сохранены, и преобразовать их в UTC (обратимая операция).
Альтернативы

A – преобразовать в timestamptz, но это полумера.
C – избыточно, сложно.
D – неприемлемо для международных систем.

Реальный пример

Booking.com хранит даты заезда в UTC, а показывает в локали пользователя.
Требования
Все временные метки в БД – TIMESTAMP WITH TIME ZONE или timestamp в UTC.
Конвертация происходит на уровне представления.

☀Объяснение:

Что демонстрирует кандидат
Понимание, что оценка без контекста — гадание.
Умение задавать уточняющие вопросы:
Какой провайдер (Google, собственный)?
Есть ли готовый SDK, примеры?
Требуется ли поддержка мобильных приложений?
Как обновлять токены, как хранить секреты?
Выделение рисков: если документация плохая или провайдер меняет API, то срок может вырасти вдвое.

Почему правильный ответ B
Интервьюеры хотят видеть аналитический склад ума, а не цифру.

Реальный опыт
Кандидат, который задавал вопросы, получил оффер, а тот, кто назвал 3 дня без уточнений — нет.

Вывод
На собеседовании никогда не давайте оценки без уточнения контекста.

80% системных аналитиков заваливают собеседования из-за глупых ошибок

Самый простой способ подготовиться к собеседованию — это послушать, как его проходят другие.

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

Что внутри:
💘 Разборы живых записей — от проектирования API до работы с БД
💘 Ключевые вопросы лидов из бигтеха
💘 Анализ ответов — где кандидат «поплыл» и как нужно было ответить правильно

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

☀Объяснение:

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

Что такое XOR-шлюз
Исключающий шлюз (XOR) имеет один вход и несколько выходов (или наоборот, несколько входов и один выход при слиянии). При ветвлении он активирует ровно один путь, проверяя условия-охранники (например, [сумма > 1 млн] и [сумма <= 1 млн]). При слиянии он пропускает поток дальше, когда завершится любой из входящих путей (но в данном случае слияние не требуется).

Как моделировать
Шаг 1: после создания заявки — XOR-шлюз с двумя исходящими потоками:
Условие 1: сумма > 1 млн → задача «Подпись финдиректора».
Условие 2: сумма ≤ 1 млн → задача «Подпись руководителя отдела».
Затем оба потока сходятся в общую точку (например, в задачу «Передать в бухгалтерию»).

Почему не другие шлюзы
AND — запустил бы оба пути одновременно (подпись и финдиректора, и руководителя) и потребовал бы завершения обоих, что неверно.
OR — мог бы активировать один или оба пути, тоже не подходит.
Событие-таймер — ждёт наступления времени, не имеет отношения к условиям.

Реальный пример
В ERP-системе закупки до определённой суммы утверждает начальник отдела, выше — финансовый контролёр. XOR-шлюз идеально отображает это правило.

Вывод
XOR применяется для ветвления «или-или» на основе бизнес-данных. Аналитик должен правильно выбрать тип шлюза в зависимости от логики.