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

Основной принцип
В распределённых системах нельзя одновременно обновить все сервисы. Нужно делать обратно-совместимые изменения (additive changes). То есть сначала добавить новое поле в API, не удаляя старое. Старые клиенты продолжают работать. Затем обновить потребителей, чтобы они начали использовать новое поле. И только когда все потребители перешли на новую версию, можно удалить старое поле (ломающее изменение).

Как избежать простоя

Фаза 1: добавить новый параметр в запрос (опционально). Старый сервис его игнорирует.
Фаза 2: обновить все вызывающие сервисы, чтобы они передавали новый параметр.
Фаза 3: изменить логику сервиса-приёмника, чтобы он требовал новый параметр.
На каждом этапе система продолжает работать.

Почему A не подходит
Остановка всех сервисов — это downtime, которого можно избежать.

C и D — нереалистичны.

Реальный инструмент
Feature flags, versioned APIs, graceful shutdown. Аналитик должен в требованиях указывать, что изменения API должны быть обратно совместимыми или идти через версионирование.

⁉️ Устал искать интересные каналы про Искусственный интеллект?

📁 СОХРАНИ СЕБЕ ЧТОБЫ НЕ ПОТЕРЯТЬ

В этой папке собраны каналы по ИИ, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.

😏 ЗАБИРАЙ ПАПКУ ТУТ

⏰ Папка действует 72 часа.

🤩 Организаторы: Green.Papka

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

Почему это реальный кейс
Каждый спринт разработчики сталкиваются с дилеммой: баг фиксить или фичу делать. Баг теряет 5% заказов — это реальные деньги здесь и сейчас. Фича даст +10% продаж, но не сразу и с риском. Без аналитика команда может выбрать неоптимально.

Что делает хороший аналитик
Собирает цифры:
Потери от бага = 5% от текущей выручки (например, 1 млн руб./день).
Ожидаемый доход от фичи = 10% прироста, но после внедрения (через 3 недели).
Показывает бизнесу. Уточняет, можно ли отложить баг на час (неделю) – обычно нельзя, так как потери растут. Затем организует встречу со стейкхолдерами (владельцем продукта, маркетингом, поддержкой) и вместе определяют приоритет по бизнес-ценности. Возможные варианты:
Сначала фикс бага (1 неделя), затем MVP фичи (2 недели).
Перенести фичу на следующий спринт, но получить план компенсации (скидка на доставку).
Важно зафиксировать решение в протоколе, чтобы потом не было споров. Аналитик не должен выбирать сам — он фасилитатор.
Что будет, если выбрать A (фичу) без согласования
Бизнес потеряет 5% заказов за 3 недели; через месяц фича может не окупить потерь.
Что будет, если B (сделать всё, сократив тестирование)
Выпустите баг ещё больше, либо фича окажется с дефектами.

Реальный пример
В Delivery Club аналогичный конфликт решили взвешиванием: баг с потерей заказов — must have, новая фича — could have. Бизнес согласился отложить фичу.

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

Проблема

Письма клиентам (со сбросом пароля, подтверждением заказа) не должны дублироваться. Но все внешние сервисы могут выдавать временные ошибки 5xx, и клиент, повторив запрос, рискует получить два письма.
Решение – идемпотентность на стороне получателя
В запросе на отправку письма нужно передавать уникальный идентификатор (например, message_id = UUID, связанный с заказом или пользователем). Почтовый сервис должен хранить уже обработанные ID (хотя бы в течение суток) и при повторном запросе с тем же ID возвращать успех, не отправляя письмо повторно.

Детали в требованиях

«Перед отправкой письма система должна генерировать уникальный message_id (например, order_id + timestamp). Передавать его в заголовке или теле запроса».
«Email-сервис должен реализовать проверку идемпотентности: если запрос с таким message_id уже обрабатывался, вернуть 200 OK без повторной отправки».
«Хранить ID не менее 24 часов для защиты от коллизий при сетевых задержках».
Почему не подходят другие варианты

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

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

Банк отправлял SMS с одноразовым кодом. Из-за ошибки в биллинге при повторе отправлялось две SMS. Клиенты путали код. После внедрения message_id дубликаты прекратились.

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

Почему партиционирование не решает
Партиционирование по дате уменьшит объём сканирования, если в 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 дня. Вместо срыва спринта договорились перенести менее важную фичу. Изменение задокументировали.