4805. В логистической компании Kafka используется для передачи событий о перемещении грузов. Один из консьюмеров (система учёта) периодически падает из-за ошибки в формате данных.
Какое архитектурное требование аналитик должен был добавить?
Какое архитектурное требование аналитик должен был добавить?
Anonymous Quiz
5%
Увеличить retention сообщений до 30 дней
78%
Настроить Dead Letter Queue для сообщений
6%
Добавить мониторинг лага потребителя
12%
Переключить консьюмера в режим at-most-once
Please open Telegram to view this post
VIEW IN TELEGRAM
4806. Фотохостинг (как Instagram) должен быстро показывать ленту друзей. Создание поста — редко, а просмотр — постоянно. Какую архитектуру выбрать, чтобы не нагружать базу при чтении?
Anonymous Quiz
12%
Всегда читать посты напрямую из базы с кэшем на уровне запроса
49%
Генерировать ленту заранее — при создании поста разослать его ID всем друзьям в их ленту
13%
Использовать синхронную репликацию базы между всеми серверами
25%
Хранить посты в S3, а метаданные в DynamoDB
В фотохостинге соотношение чтения и записи огромное (например, 1000 просмотров на один пост). Если при каждом просмотре ленты делать сложный запрос к базе (получить посты друзей с пагинацией), база ляжет под нагрузкой даже при скромном количестве пользователей.
Решение — fan-out на запись
Когда пользователь создаёт пост, система не ждёт, пока друзья его увидят. Она заранее (асинхронно) раскладывает ID поста в ленту каждого друга. Лента каждого пользователя — это просто список ID постов (например, в Redis или другой кэш-структуре), отсортированный по времени. При чтении лента отдаётся мгновенно, без обращения к основной базе. Это называется push-модель (fan-out на запись).
Альтернатива (плохая для нагрузки)
Read fan-out (pull) — при каждом запросе ленты искать посты всех друзей. Это убивает производительность.
Почему другие варианты не подходят
A — всё равно каждый запрос нагрузки базу.
C — репликация не решает логику сбора ленты.
D — выбор хранилища не решает проблему: нужна стратегия подготовки ленты.
Реальный пример
Twitter раньше использовал pull-модель и испытывал проблемы. Перешёл на push для активных пользователей и гибридный подход. Instagram и Facebook генерируют ленту заранее.
Что должен зафиксировать аналитик
«При создании поста его идентификатор должен быть доставлен в ленты всех подписчиков через очередь».
«Лента пользователя хранится в быстром кэше (Redis) в виде отсортированного списка».
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
4807. На собеседовании спрашивают: «Как бы вы оценили, сколько времени займёт интеграция с новым платёжным шлюзом?». Какой лучший ответ?
Anonymous Quiz
0%
Назвать конкретное число дней, основанное на опыте
100%
Сказать, что нужно уточнить требования, документацию API, прототип, а затем дать диапазон с рисками
0%
Ответить, что это зависит от команды, и уйти от ответа
0%
Назвать максимально большую оценку, чтобы перестраховаться
Настоящий опытный аналитик не оценивает без контекста. Он задаёт уточняющие вопросы:
Есть ли документация по API? Какие протоколы?
Нужна ли аутентификация, какие схемы?
Будет ли шлюз обрабатывать идемпотентность?
Какой объём трафика?
Какая команда будет заниматься?
Затем предлагает диапазон оценок (например, 2–4 недели) с факторами риска (сложность аутентификации, отсутствие тестового стенда). Такой подход показывает системное мышление.
Чего ждут интервьюеры
Не названия цифр, а методологии оценки (например, T-shirt sizes, planning poker, аналогии с похожими задачами).
Умение выявлять неизвестное.
Понимание, что интеграция — это не только код, но и тестирование, документирование, отладка.
Почему не другие варианты
A — называется число без анализа, что является красным флагом (не учитывает нюансы).
C — уход от ответа показывает неуверенность.
D — завышенная оценка без объяснений — тоже плохо.
Реальный совет
На собеседовании скажите: «Я бы начал с изучения документации, составил список задач, выделил неизвестные зоны и предложил бы спринт на исследование, после которого дал бы прогноз». Это демонстрирует проактивность.
Please open Telegram to view this post
VIEW IN TELEGRAM
4808. В спецификации к системе управления складом написано: «Система должна предотвращать отгрузку товара, если его нет в наличии». Разработчик сделал проверку только на момент отгрузки. Как улучшить требование?
Anonymous Quiz
3%
Указать, что блокировка должна быть на уровне базы данных
95%
Уточнить,что система должна резервировать товар на этапе создания заказа,а не только перед отгрузкой
3%
Добавить требование к времени выполнения проверки
0%
Запретить отгрузку в ночное время
Требование «предотвращать отгрузку, если нет в наличии» слишком узкое. Оно описывает только финальную проверку. Но товар может быть продан (через другой склад или онлайн) после того, как его зарезервировали, но до отгрузки. В реальности нужна блокировка товара на время процесса: как только клиент добавил товар в корзину или создал заказ, товар должен быть зарезервирован на складе (уменьшать доступное количество). И только потом отгрузка проверяет уже зарезервированный товар.
Улучшенное требование
«При создании заказа система должна зарезервировать товар на складе, уменьшив доступный остаток».
«Если резервирование невозможно (остаток 0), пользователь получает сообщение».
«При отгрузке система проверяет, что зарезервированный товар всё ещё доступен (не снят другим процессом)».
Почему это важно
Это предотвращает двойные продажи и негативный опыт клиентов. Аналитик должен декомпозировать процесс: резервирование, блокировка, отгрузка, а не просто «предотвращать отгрузку».
Реальный кейс
Крупный ритейлер пострадал от такой ошибки: люди заказывали товар, приезжали забирать, а его уже продали через кассу. Внедрили резервирование при создании заказа.
Please open Telegram to view this post
VIEW IN TELEGRAM
4809. Команда выкатывает обновление микросервиса, которое меняет формат запроса к другому сервису. Новая версия совместима со старым форматом, но новый формат не поддерживается старым сервисом. Как организовать rollout без простоя?
Anonymous Quiz
3%
Остановить все сервисы, обновить их по очереди и включить
97%
Использовать стратегию «сначала обратно-совместимые изменения, затем обновить потребителей
0%
Сделать обновление за один день, ничего не проверяя
0%
Переписать всё заново
В распределённых системах нельзя одновременно обновить все сервисы. Нужно делать обратно-совместимые изменения (additive changes). То есть сначала добавить новое поле в API, не удаляя старое. Старые клиенты продолжают работать. Затем обновить потребителей, чтобы они начали использовать новое поле. И только когда все потребители перешли на новую версию, можно удалить старое поле (ломающее изменение).
Как избежать простоя
Фаза 1: добавить новый параметр в запрос (опционально). Старый сервис его игнорирует.
Фаза 2: обновить все вызывающие сервисы, чтобы они передавали новый параметр.
Фаза 3: изменить логику сервиса-приёмника, чтобы он требовал новый параметр.
На каждом этапе система продолжает работать.
Почему A не подходит
Остановка всех сервисов — это downtime, которого можно избежать.
C и D — нереалистичны.
Реальный инструмент
Feature flags, versioned APIs, graceful shutdown. Аналитик должен в требованиях указывать, что изменения API должны быть обратно совместимыми или идти через версионирование.
Please open Telegram to view this post
VIEW IN TELEGRAM
В этой папке собраны каналы по ИИ, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.
Please open Telegram to view this post
VIEW IN TELEGRAM
4810. Спринт на 3 недели. Есть критический баг (теряются 5% заказов) и новая фича (повысит продажи на 10%). На оба задачи не хватает времени. Что делать аналитику?
Anonymous Quiz
0%
Взять фичу, так как она даст больше прибыли
100%
Организовать встречу с бизнесом, показать цифры и решить, что важнее, зафиксировать компромисс
0%
Сделать и то, и другое, сократив тестирование
0%
Отдать решение архитектору
Каждый спринт разработчики сталкиваются с дилеммой: баг фиксить или фичу делать. Баг теряет 5% заказов — это реальные деньги здесь и сейчас. Фича даст +10% продаж, но не сразу и с риском. Без аналитика команда может выбрать неоптимально.
Что делает хороший аналитик
Собирает цифры:
Потери от бага = 5% от текущей выручки (например, 1 млн руб./день).
Ожидаемый доход от фичи = 10% прироста, но после внедрения (через 3 недели).
Показывает бизнесу. Уточняет, можно ли отложить баг на час (неделю) – обычно нельзя, так как потери растут. Затем организует встречу со стейкхолдерами (владельцем продукта, маркетингом, поддержкой) и вместе определяют приоритет по бизнес-ценности. Возможные варианты:
Сначала фикс бага (1 неделя), затем MVP фичи (2 недели).
Перенести фичу на следующий спринт, но получить план компенсации (скидка на доставку).
Важно зафиксировать решение в протоколе, чтобы потом не было споров. Аналитик не должен выбирать сам — он фасилитатор.
Что будет, если выбрать A (фичу) без согласования
Бизнес потеряет 5% заказов за 3 недели; через месяц фича может не окупить потерь.
Что будет, если B (сделать всё, сократив тестирование)
Выпустите баг ещё больше, либо фича окажется с дефектами.
Реальный пример
В Delivery Club аналогичный конфликт решили взвешиванием: баг с потерей заказов — must have, новая фича — could have. Бизнес согласился отложить фичу.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
4811. Сервис отправки email иногда отвечает 500 ошибкой. При повторе письмо уходит дважды. Как требование должно защитить от дублей?
Anonymous Quiz
0%
Не повторить, а ловить ошибку и оповещать администратора
98%
Добавить уникальный идентификатор письма и проверять на стороне email-сервиса, было ли такое письмо
0%
Увеличить таймаут соединения
2%
Перестать пользоваться этим сервисом