Top Products Dashboard - это кейс про построение аналитического serving слоя, где нужно одновременно держать fast query latency, консистентность KPI и управляемую стоимость вычислений. На интервью проверяют, как вы разделяете realtime и batch контуры и как объясняете freshness метрик бизнесу.
Источник
Acing the System Design Interview
Глава 17: Design Top Products Dashboard с фокусом на pre-aggregations и reconciliation.
Где этот паттерн встречается
- E-commerce BI: топ товаров по выручке/марже/конверсии в near-realtime.
- Маркетплейс аналитика: рейтинг SKU по регионам, каналам и promo-кампаниям.
- Executive dashboards: единая витрина KPI с drill-down в операционные контуры.
- Growth-команды: быстрая проверка эффекта кампаний и ассортиментных решений.
Функциональные требования
Core Dashboard API
GET /top-products- top-N по выбранной метрикеGET /kpi-breakdown- drill-down по измерениямGET /freshness- watermark и version метрикPOST /reconcile- пересчёт/коррекция диапазона
Product/Analytics функции
- Фильтры по периоду, региону, категории, каналу продаж
- Поддержка нескольких формул ранжирования (revenue/margin/conversion)
- Role-based доступ к витринам и export policy для чувствительных отчётов
- Explainability для KPI: источник, версия формулы, время последнего пересчёта
Нефункциональные требования
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Dashboard response (p95) | < 300ms | Интерактивная аналитика для бизнеса без задержек |
| Data freshness SLA | 1-5 минут | Оперативные решения по ассортименту и ценам |
| Metric drift vs finance | < 0.2% | Согласованность BI и финансовых отчётов |
| Availability | 99.9% | Критичный контур для exec/product команд |
| Backfill impact | Без деградации online path | Пересчёты не должны ломать runtime SLA |
High-Level Architecture
Теория
ETL/ELT архитектура
Слои ingestion, трансформаций и serving витрин для аналитических платформ.
High-Level Architecture
events -> aggregations -> serving -> reconciliationСхема разделяет ingest pipeline, query serving path и контур reconciliation/backfill.
Архитектура отделяет ingest/aggregation контур от query-serving path и отдельного reconcile/backfill loop, чтобы одновременно держать latency, freshness и консистентность KPI.
Write/Read Paths
Write/Read Paths
Как метрики пишутся в serving-контур и как dashboard читает агрегаты при высокой нагрузке.
Write path: события проходят ingestion и stream aggregation, затем записываются в serving-таблицы и метаданные freshness/version.
Events Ingest
orders/clicks stream
Продуктовые события поступают через ingestion API и валидируются по контрактам.
Stream Bus
partitioned log
События публикуются в stream bus и распределяются по aggregation jobs.
Aggregation Jobs
windowed compute
Строятся window/materialized агрегаты по ключевым dimension combinations.
Serving Store
OLAP views
Top-N и KPI сохраняются в serving таблицах с индексами под dashboard фильтры.
Freshness Metadata
watermark/version
Записываются watermark, formula_version и source метки для explainability.
Events Ingest
orders/clicks stream
Продуктовые события поступают через ingestion API и валидируются по контрактам.
Stream Bus
partitioned log
События публикуются в stream bus и распределяются по aggregation jobs.
Aggregation Jobs
windowed compute
Строятся window/materialized агрегаты по ключевым dimension combinations.
Serving Store
OLAP views
Top-N и KPI сохраняются в serving таблицах с индексами под dashboard фильтры.
Freshness Metadata
watermark/version
Записываются watermark, formula_version и source метки для explainability.
Write path checkpoints
- •Schema contracts проверяются на входе, чтобы не загрязнять агрегаты.
- •Агрегации должны быть идемпотентными для safe retry при сбоях stream jobs.
- •Watermark и formula_version пишутся вместе с KPI, иначе freshness и explainability теряются.
Консистентность метрик и отказоустойчивость
Глубже
ClickHouse обзор
Материализованные представления, columnar storage и оптимизация аналитических запросов.
Dual-truth модель
Для устойчивой BI-витрины обычно разводят online и reconciliation контуры:
dashboard_metrics = stream_aggregates(events) finance_metrics = batch_recompute(raw_events)
- Stream path - быстрый отклик и near-realtime freshness
- Batch path - точность и контроль исторических корректировок
- Reconcile - фиксация и объяснение расхождений между контурами
Операционные контуры
- Schema contracts: защита от "тихой" поломки метрик при изменении событий.
- Query guardrails: лимиты/timeout для дорогих ad-hoc запросов.
- Freshness watermark: обязательный сигнал актуальности на UI уровне.
- Backfill throttling: пересчёт истории без saturation serving кластера.
Риски и типовые ошибки
- OLTP abuse: попытка строить BI напрямую на production транзакционной БД.
- Hidden freshness: пользователь видит KPI, но не понимает, насколько они устарели.
- Formula drift: изменение расчётов без версии ломает сравнимость метрик во времени.
- Expensive ad-hoc: отсутствие query governance взрывает стоимость инфраструктуры.
- No reconcile path: расхождения с finance не диагностируются и не исправляются.
Что важно проговорить на интервью
- Где проходит граница между realtime dashboard и финансово-значимой отчётностью.
- Как устроена версия формул KPI и как обеспечивается воспроизводимость расчётов.
- Какие SLO мониторятся: response latency, freshness lag, drift, query cost.
- Как pipeline ведёт себя при late events, schema change и массовом backfill.