Инженерные компромиссы
Зачем это на интервью
У проектных задач редко есть единственно правильная архитектура. E4 должен назвать ограничения, сравнить варианты по наблюдаемым последствиям и выбрать вариант под текущую нагрузку и команду. Ответ «зависит» недостаточен без осей выбора, допущений и способа проверить решение после запуска.
Минимум для E4
- Сначала зафиксировать функциональные и нефункциональные требования.
- Сравнить минимум два варианта по задержке, надёжности, стоимости, сложности и времени поставки.
- Явно назвать допущения и самый опасный риск выбранного решения.
- Предложить метрику, лимит или тест, который подтвердит либо опровергнет решение.
Компромисс — не ошибка и не голосование за любимую технологию. Он появляется, когда улучшение одного свойства ухудшает другое: синхронная запись даёт простую консистентность, но повышает latency; асинхронная очередь разгружает запрос, но добавляет eventual consistency, дедупликацию и операционную нагрузку.
Короткая структура решения: контекст → варианты → критерии → выбор → риск → проверка. Она подходит и для кода, и для системы. Например, перед выбором кэша нужно узнать допустимую устарелость данных, профиль чтения/записи, цену промаха, объём данных и режим деградации.
Углубление для E5/Senior
E5 переводит спор в управляемый эксперимент: задаёт SLO, бюджет ошибок, целевой RPS, стоимость сопровождения и владельца решения. Он учитывает необратимость: публичный API, схема данных и межкомандный контракт требуют более осторожного дизайна, чем внутренний пакет. Обратимые решения стоит принимать быстрее и сопровождать feature flag, метриками и планом rollback.
Полезно отделять фундаментальные ограничения от локальных. Теорема CAP не оправдывает произвольную eventual consistency: нужно назвать, какое именно чтение может быть устаревшим, сколько времени, как пользователь увидит статус и как система исправит расхождение. Аналогично «микросервисы масштабируются» не является аргументом, если bottleneck — одна база или у команды нет зрелой эксплуатации.
Ключевые понятия
| Ось | Что измерять | Типичный конфликт |
|---|---|---|
| Производительность | p95/p99 latency, throughput | Синхронность против скорости ответа |
| Надёжность | error rate, RTO/RPO | Репликация против стоимости и сложности |
| Консистентность | допустимая устарелость, инварианты | Availability против строгой координации |
| Сопровождаемость | когнитивная нагрузка, MTTR | Гибкость против простоты |
| Стоимость | инфраструктура и время команды | Резервирование против бюджета |
Матрица нужна для рассуждения, а не для ложной точности. Не ставьте баллы без данных: лучше описать направление эффекта и измерение. Критерии должны вытекать из потребности, например «платёж нельзя потерять» важнее «обработчик должен быть самым коротким».
Типовые вопросы
- Как отвечать на вопрос «монолит или микросервисы»?
- Начать с команды, доменных границ, независимого deploy, нагрузки и операционной зрелости; для раннего продукта часто выбрать модульный монолит.
- Когда выбрать синхронный вызов, а когда очередь?
- Синхронно — когда ответ нужен пользователю сразу и зависимость укладывается в latency budget; очередь — для терпимых к задержке, повторяемых задач с идемпотентным потребителем.
- Почему кэш — не бесплатная оптимизация?
- Он добавляет stale data, инвалидацию, прогрев, наблюдаемость и режимы частичного отказа.
- Как принять решение при неполных данных?
- Зафиксировать допущения, выбрать обратимый вариант, поставить метрики и дату пересмотра.
- Что означает «eventual consistency» для пользователя?
- Нужно определить видимое состояние, срок сходимости, повторную обработку и способ разрешения конфликта.
- Когда технический долг оправдан?
- Когда он осознан, ограничен по области, даёт ценность сейчас и имеет владельца, триггер погашения и оценённый риск.
Практика
- Выберите способ отправки письма после регистрации: синхронный HTTP-вызов или очередь.
- Критерии готовности: записаны SLA ответа и допустимая задержка письма; названы минимум два риска каждого варианта; выбранный путь содержит таймауты, retry/идемпотентность по необходимости и метрику успеха.
- Спроектируйте кэш профиля пользователя.
- Критерии готовности: определены TTL и источник истины; описаны промах, неработающий кэш и инвалидация; есть метрики hit ratio, stale-read и p95 latency; указан критерий отказа от кэша.
Частые ошибки и ловушки
- Выбирать технологию до формулировки ограничений и SLO.
- Перечислять преимущества, не называя цену и режим отказа.
- Считать горизонтальное масштабирование заменой ограничениям базы данных или внешнего API.
- Добавлять очередь без идемпотентности, DLQ, мониторинга задержки и стратегии повторов.
- Прятать допущения вместо того, чтобы сделать их проверяемыми.
Связанные темы
Источники
- Martin Kleppmann. Designing Data-Intensive Applications, 2017.
- Google. Site Reliability Engineering: Service Level Objectives.
- AWS. Well-Architected Framework.