Эта глава из темы 3 фокусируется на data-intensive потоки, индексирование и feed-механики. Здесь важно не только предложить рабочую схему, но и показать, как она ведёт себя при росте нагрузки и сбоях.
Используйте структуру разбора: требования -> архитектура -> критический deep dive -> эволюция. Такой подход делает решение прозрачным и интервью-устойчивым.
Pipeline Thinking
Критичны ingestion, partitioning, deduplication и задержки между стадиями обработки.
Serving Layer
Решения по индексам, cache locality и query path определяют пользовательскую latency.
Consistency Window
Явно фиксируйте, где допустима eventual consistency и где требуется stronger guarantees.
Cost vs Freshness
Балансируйте скорость обновления данных и стоимость вычислений/хранения.
Playbook прохождения кейса
Опишите data lifecycle
Фаза 1От источника события до serving-слоя с явной схемой transformation-пайплайна.
Проектируйте read/write пути
Фаза 2Отдельно оптимизируйте ingest throughput и user-facing query latency.
Задайте consistency contract
Фаза 3Определите допустимое окно рассинхронизации и стратегии компенсации.
Планируйте рост x10/x100
Фаза 4Покажите эволюцию partitioning, indexing и storage tiers при росте нагрузки.
Связанная глава
Machine Learning System Design
Фреймворк для ML-кейсов: постановка задачи, метрики, данные, продакшн-риски.
Recommendation System - это классический multi-stage кейс, где нужно одновременно управлять релевантностью, latency и стоимостью. На интервью проверяют, умеете ли вы декомпозировать систему на candidate generation, ranking и policy-слой, а также объяснять, какие метрики действительно отражают бизнес-эффект.
Функциональные требования
- Формировать персонализированные рекомендации для home/feed страницы.
- Поддерживать candidate generation, ranking и re-ranking с бизнес-ограничениями.
- Учитывать implicit feedback (просмотры, лайки, досмотры, клики) и explicit сигналы.
- Показывать explainability-сигналы: почему рекомендация была показана пользователю.
Нефункциональные требования
- p95 latency ответа рекомендаций < 200 мс на online path.
- Гибкая эволюция моделей без downtime и с контролем качества по holdout-группам.
- Управляемая стоимость инференса и feature storage при росте MAU.
- Изоляция деградаций: fallback-режимы при проблемах model serving или feature store.
Масштаб и предположения
| Параметр | Оценка | Почему важно |
|---|---|---|
| DAU | 12M | Платформа с крупной ежедневной аудиторией и персональной лентой. |
| Recommendation QPS | 180k (peak) | Пики утренних/вечерних сессий и высокий fan-out по поверхностям выдачи. |
| Candidate pool | 10M+ объектов | Большой каталог контента/товаров с быстрым обновлением доступности. |
| Feature freshness | 1-5 минут | Сценарии, где recent intent заметно влияет на релевантность. |
| Availability | 99.95% | Рекомендации влияют на core-конверсию и удержание. |
High-Level Architecture
Stage 1: Candidate Generation
Быстрый retrieval из нескольких источников: collaborative candidates, content-based retrieval, trending/popular, editorial boosts.
Stage 2: Ranking
ML ranking с feature store (online/offline), user/item/context features и multi-objective score (CTR, watch-time, conversion).
Stage 3: Re-ranking & Policy Layer
Диверсификация, бизнес-правила, caps, safety/abuse фильтры, cold-start fallback и итоговая выдача.
Типичный write/read цикл: события пользователя идут в streaming bus, обновляют признаки в online feature store, ranking-сервис запрашивает кандидатов из retrieval-контуров и возвращает итоговый список после policy-фильтрации.
Deep Dives и trade-offs
Freshness vs стабильность
Чем чаще обновляется модель или фичи, тем выше адаптивность к intent, но растут риски дрейфа качества и операционная нагрузка на serving pipeline.
Exploration vs exploitation
Сильная эксплуатация повышает краткосрочный CTR, но может ограничивать discovery. Controlled exploration (например, bandit-слой) уменьшает эффект замкнутого пузыря.
Точность модели vs latency/cost
Более сложная модель улучшает качество ранжирования, но может нарушить latency budget и увеличить стоимость инференса. Нужны многоступенчатые модели и budget-aware routing.
Персонализация vs explainability
Глубокая персонализация сложнее объясняется пользователю и внутренним стейкхолдерам. Обычно добавляют reason codes и прозрачные policy-ограничения на финальном слое.
Типичные антипаттерны
Единый heavy ranker без предварительного candidate pruning, который ломает latency budget на пике.
Обучение только на кликах без учета delayed metrics (удержание, долгий watch-time, отписки).
Отсутствие fallback-стратегий: при сбое feature store рекомендации исчезают полностью.
Нет мониторинга distribution shift: оффлайн метрики хорошие, online KPI деградируют неделями.
Что проговорить на интервью
- Как устроен online path от запроса пользователя до ответа и где самый дорогой компонент?
- Какие метрики вы выберете: offline (NDCG/Recall@K) и online (CTR, dwell time, conversion)?
- Как решаете cold start для новых пользователей и новых объектов каталога?
- Какой план деградации при недоступности feature store, ANN индекса или model serving?
References
- Deep Neural Networks for YouTube Recommendations - Классическая публикация про двухэтапную архитектуру retrieval + ranking.
- Netflix Tech Blog - Практические кейсы эволюции recommendation платформы в продакшене.
Связанные главы
- Search System - Близкий retrieval/ranking паттерн и компромиссы качества поиска.
- Twitter/X - Ленты, fan-out и персонализация на высоком QPS.
- A/B Testing платформа - Экспериментальная проверка качества рекомендаций и guardrail-метрик.
- Precision и Recall - База для выбора метрик ранжирования и оценки качества выдачи.