Data Platform System Design — DE Interview PrepСистемный дизайн платформы данных — Подготовка к DE-интервью

The interviewer scores how you reason, not how fast you draw boxes. Say this scaffold out loud and walk it.

Интервьюер оценивает как ты рассуждаешь, а не как быстро рисуешь прямоугольники. Проговори этот каркас вслух и пройди по нему.

 ┌─ 1. CLARIFY ──────┐  ┌─ 2. PROPOSE ──────┐  ┌─ 3. TRADE-OFFS ───┐  ┌─ 4. DEEP-DIVE ────┐  ┌─ 5. FAILURE/OPS ──┐
 │ restate prompt    │  │ end-to-end at a    │  │ for each choice:   │  │ they pick OR you  │  │ replay/backfill   │
 │ volume? latency?  │─▶│ high level:        │─▶│ name the alt + why │─▶│ volunteer the     │─▶│ observability     │
 │ freshness SLA?    │  │ ingest→land→       │  │ you chose it       │  │ domain one:       │  │ what breaks &     │
 │ revisions? consis-│  │ validate→model→    │  │                    │  │ revisions/PIT or  │  │ how you detect    │
 │ tency? consumers? │  │ serve (+QC/lineage)│  │                    │  │ the quality gate  │  │                   │
 └───────────────────┘  └────────────────────┘  └────────────────────┘  └───────────────────┘  └───────────────────┘
   ~3-5 min                ~5-8 min                 woven in                ~8-10 min               close strong
    

 ┌─ 1. УТОЧНЕНИЕ ────┐  ┌─ 2. ПРЕДЛОЖЕНИЕ ──┐  ┌─ 3. КОМПРОМИССЫ ──┐  ┌─ 4. УГЛУБЛЕНИЕ ───┐  ┌─ 5. СБОИ/ОПС ─────┐
 │ переформулировать │  │ end-to-end на      │  │ для каждого выбора:│  │ они выбирают ИЛИ  │  │ replay/backfill   │
 │ объём? задержка?  │─▶│ высоком уровне:    │─▶│ назвать альтернативу│─▶│ ты предлагаешь    │─▶│ наблюдаемость     │
 │ SLA свежести?     │  │ ingest→land→       │  │ + почему выбрал    │  │ доменный аспект:  │  │ что ломается &    │
 │ ревизии? согласов.│  │ validate→model→    │  │                    │  │ ревизии/PIT или   │  │ как обнаруживаешь │
 │ консьюмеры?       │  │ serve (+QC/lineage)│  │                    │  │ гейт качества     │  │                   │
 └───────────────────┘  └────────────────────┘  └────────────────────┘  └───────────────────┘  └───────────────────┘
   ~3-5 мин                ~5-8 мин                 вплетено               ~8-10 мин               завершить сильно
    

Ask about each. Memorize the acronym mentally: V-L-F-C-R (Volume, Latency, Freshness, Consistency, Revisions) + consumers.

Спроси про каждую. Запомни мнемонику: V-L-F-C-R (Volume, Latency, Freshness, Consistency, Revisions) + консьюмеры.

 VENDORS              INGEST            LAND (bronze)      VALIDATE+CONFORM (silver)   MODEL (gold)        SERVE
 ┌────────┐ push/pull ┌──────────┐     ┌────────────┐     ┌─────────────────────┐    ┌───────────┐     ┌──────────────┐
 │ SFTP   │──────────▶│ adapters │────▶│ IMMUTABLE  │────▶│ parse · type ·      │───▶│ canonical │────▶│ Terminal     │
 │ API    │           │ per feed │     │ raw object │     │ QUALITY GATE        │    │ long fmt  │     │  (lookups)   │
 │ Kafka  │           │ (registry│     │ store      │     │ (fail-closed) ·     │    │ +vintages │     │ analytics    │
 │ files  │           │  driven) │     │ part by    │     │ quarantine bad rows·│    │ +derived  │     │  (scans)     │
 └────────┘           └──────────┘     │ load_date  │     │ conform to ONE model│    │ series    │     │ Enterprise/DL│
                                        └────────────┘     └─────────────────────┘    └───────────┘     │  (bulk)      │
                                                                                                          └──────────────┘
 ══ CROSS-CUTTING ══▶  orchestration (release-calendar as data) · observability (freshness/completeness/validity) · lineage + metadata catalog
    

 ПОСТАВЩИКИ           INGEST            LAND (bronze)      VALIDATE+CONFORM (silver)   MODEL (gold)        SERVE
 ┌────────┐ push/pull ┌──────────┐     ┌────────────┐     ┌─────────────────────┐    ┌───────────┐     ┌──────────────┐
 │ SFTP   │──────────▶│ адаптеры │────▶│ НЕИЗМЕНЯЕМОЕ│────▶│ parse · type ·      │───▶│ каноничный│────▶│ Terminal     │
 │ API    │           │ на фид   │     │ сырое хран. │     │ ГЕЙТ КАЧЕСТВА       │    │ long fmt  │     │  (lookups)   │
 │ Kafka  │           │ (реестр- │     │ объектов    │     │ (fail-closed) ·     │    │ +vintages │     │ аналитика    │
 │ файлы  │           │  управл.)│     │ part по     │     │ карантин плохих ·   │    │ +производные│   │  (сканы)     │
 └────────┘           └──────────┘     │ load_date   │     │ conform к ОДНОЙ     │    │ ряды      │     │ Enterprise/DL│
                                        └────────────┘     │ модели              │    └───────────┘     │  (bulk)      │
                                                            └─────────────────────┘                      └──────────────┘
 ══ СКВОЗНЫЕ ══▶  оркестрация (календарь релизов как данные) · наблюдаемость (свежесть/полнота/валидность) · lineage + каталог метаданных
    

Lakehouse vs warehouse vs time-series DB

Lakehouse vs хранилище vs time-series DB

My answer: lakehouse for immutable landing + archive feeding a columnar warehouse for the conformed/served layer. Not a tick-DB for monthly data. Lakehouse = openness + cost + replay; warehouse = query perf + concurrency + governance. Using both is the standard split, not a contradiction.

Мой ответ: lakehouse для неизменяемого landing + архива, питающего колоночное хранилище для conformed/served слоя. Не tick-DB для месячных данных. Lakehouse = открытость + цена + replay; хранилище = query perf + конкуренция + governance. Использовать оба — это стандартное разделение, а не противоречие.

Partitioning for time-series

Партиционирование для time-series

• Partition by observation_date (coarser load_date for raw). It's what you filter and reprocess on → cheap incrementals, partition-level idempotent overwrite, pruned as-of scans.
• Cluster/sort within partition by series_id → fast single-series Terminal lookups.
• Keep revisions inside the observation_date partition → a late revision rewrites exactly one partition.
• Avoid over-partitioning (small-files / metadata bloat) AND skewed mega-partitions. Monthly macro may want monthly/per-load partitions, not daily.

• Партиционировать по observation_date (грубее load_date для сырого). Это то, по чему фильтруешь и перепроцессируешь → дешёвые инкрементали, идемпотентная перезапись на уровне партиции, pruned as-of scans.
• Cluster/сортировать внутри партиции по series_id → быстрые одноранговые Terminal lookups.
• Хранить ревизии внутри партиции observation_date → поздняя ревизия переписывает ровно одну партицию.
• Избегать избыточного партиционирования (маленькие файлы / bloat метаданных) И перекошенных мега-партиций. Месячное макро может хотеть месячные/per-load партиции, а не дневные.

The single most important econ concept. A CPI/GDP/NFP figure is revised for months; "the latest value" is not what a client knew at the time.

Самая важная концепция econ. Фигура CPI/GDP/NFP ревизуется месяцами; «последнее значение» — это не то, что клиент знал в тот момент.

# two time axes — keep BOTH
observation_date  # the period data is ABOUT (valid time)
publish_timestamp # when WE knew it (transaction time)

# grain
(series_id, observation_date,
 revision_id, publish_timestamp,
 value, unit, status)

# две временные оси — хранить ОБЕ
observation_date  # период, о котором данные (valid time)
publish_timestamp # когда МЫ узнали об этом (transaction time)

# grain
(series_id, observation_date,
 revision_id, publish_timestamp,
 value, unit, status)

One source of truth: all three read the same vintage-aware canonical model. Current and as-of are views over one table — never recompute the same number two ways (that's how a client sees a discrepancy).

Один источник правды: все три читают одну и ту же каноничную модель, осведомлённую о vintages. Current и as-of — это views поверх одной таблицы — никогда не пересчитывай одно число двумя способами (так клиент видит расхождение).

Atomic release visibility

Атомарная видимость релиза

Stage-then-swap: build the release fully in staging, validate, then make it visible in one atomic op (partition swap / view repoint / Iceberg-Delta commit). Consumers read the previous consistent state until the swap. Never publish mid-write.

Stage-then-swap: собрать релиз полностью в staging, валидировать, затем сделать видимым одной атомарной операцией (partition swap / view repoint / Iceberg-Delta commit). Консьюмеры читают предыдущее согласованное состояние до swap. Никогда не публикуй посередине записи.

Structure by WHERE (lifecycle) and WHAT (check type).

Структурировать по ГДЕ (жизненный цикл) и ЧТО (тип проверки).

Failure modes checklist (name these — strong senior signal)

Чеклист режимов сбоев (называй их — сильный сеньорский сигнал)

Replay / backfill story

История replay / backfill

• Immutable raw landing = the replay source. Re-derive any downstream state deterministically.
• Idempotent, partition-keyed reprocessing — re-run replaces partitions; backfill any range, any order, in parallel, converges.
• Triggers: bug fix, revision, new derived series, contract change → replay from raw.
• Lookback window in incrementals so late revisions to old dates aren't missed.

• Неизменяемое сырое landing = источник replay. Перевывести любое downstream-состояние детерминистски.
• Идемпотентный, partition-keyed reprocessing — перезапуск заменяет партиции; backfill любого диапазона, в любом порядке, параллельно, сходится.
• Триггеры: фикс бага, ревизия, новый производный ряд, изменение контракта → replay из сырого.
• Lookback window в инкременталах, чтобы поздние ревизии старых дат не пропустились.

Scale — where it actually bites (be honest)

Масштаб — где он действительно кусает (будь честен)

Raw row volume is NOT the challenge (macro is low-frequency). The pressure points: number of feeds (config-driven onboarding, not bespoke code) · serving concurrency (many Terminal/analytics clients) · history/vintage growth (every revision kept forever → partition + cheap object storage + archival tiers).

Объём сырых строк — НЕ челлендж (макро низкочастотный). Точки давления: количество фидов (config-driven onboarding, не bespoke-код) · конкуренция при отдаче (много Terminal/аналитики клиентов) · рост истории/vintages (каждая ревизия хранится вечно → партиция + дешёвое object storage + архивные tier).

• Storage: raw + every vintage forever can balloon → cheap object storage for landing/archive; warehouse only for hot/served; tier cold history; compress (Parquet).
• Compute: push transforms to warehouse/Spark; incremental over full-refresh; avoid full scans; separate critical-feed compute from bulk.
• Don't over-engineer: no streaming infra, no tick-DB, no real-time-everything for monthly data. Matching architecture to modest volume IS the cost optimization.

• Хранение: сырое + каждый vintage навсегда может раздуться → дешёвое object storage для landing/архива; хранилище только для горячего/served; tier холодной истории; сжимать (Parquet).
• Вычисления: пушить трансформации в хранилище/Spark; инкрементально поверх full-refresh; избегать полных сканов; разделять вычисления критичных фидов от bulk.
• Не переинженерить: никакой стримингой инфраструктуры, никакой tick-DB, никакого real-time-всего для месячных данных. Совпадение архитектуры со скромным объёмом — это и ЕСТЬ оптимизация стоимости.