Высокоуровневый дизайн и deep-dive

Две фазы, два разных проверяемых навыка

Большинство кандидатов воспринимают интервью как одно занятие: рисование. Но когда интервью разваливается, почти всегда причина в том, что кандидат потратил всё время на одну фазу и не добрался до другой.

После требований и оценки у дизайна две отдельные фазы, и они доказывают разные компетенции:

1. Высокоуровневый дизайн (HLD) — простая сквозная картина того, как запрос течёт через систему: клиент → балансировщик → сервис(ы) → хранилище(а), с кэшем, очередью или CDN там, где оценка их оправдала. Это доказывает, что ты умеешь компоновать известные компоненты в работающее целое. Должно быть быстро и почти скучно — стандартный скелет, специализированный под задачу.
2. Deep-dive — выбор одного-двух компонентов, что реально сложны для этой задачи, и их детальная инженерия. Это доказывает, что ты умеешь инженерить, не просто собирать. Здесь сеньоры отрываются от мидлов.

Ошибка — потратить всю сессию на первую фазу, добавляя всё больше коробок, делая HLD всё вычурнее, и никогда не дойти до второй. Корректный простой HLD плюс один deep-dive бьёт раскидистый HLD без глубины нигде. Интервьюер и так считает, что балансировщик ты нарисуешь; он ждёт увидеть, что ты сделаешь с частью, у которой нет стандартного ответа.

Скелет высокоуровневого дизайна

Зачем вообще нужен стандартный скелет? Он позволяет пройти HLD за две-три минуты — освобождая остаток сессии для deep-dive, где интервью реально выигрывается. Большинство систем делят скелет; твоя задача — специализировать его, не изобретать заново. Поток по умолчанию:

клиент → DNS/CDN → балансировщик → API/сервис-слой → слой данных
                                          │
                                   кэш · очередь (где оправдано)

• Клиент → CDN/DNS: статика и гео-роутинг живут на краю (юнит трафика).
• Балансировщик: разносит запросы по stateless сервис-слою (юнит трафика). Он есть, потому что оценка сказала, что одна коробка не обслужит QPS.
• Сервис-слой: stateless app-серверы, масштабируются горизонтально (юнит масштабируемости). Stateless, чтобы любой узел обслуживал любой запрос.
• Слой данных: база(ы), что выбрали паттерны доступа (урок требований). Шардированная, если оценка записи это потребовала.
• Кэш / очередь / CDN: добавляются только когда число их оправдало — кэш, потому что чтений ≫ записей; очередь, потому что путь записи нужно сделать асинхронным; CDN, потому что полоса egress была велика.

Нарисуй это за пару минут, проговаривая, почему каждая коробка тут, в терминах требования или оценки. Проговаривание — это суть: коробка без обоснования — обуза, не актив.

Набросай API и модель данных

До или рядом с HLD набросай два артефакта, что заземляют дизайн в чём-то конкретном:

API. Горстка эндпоинтов, реализующих функциональные требования — глаголы из урока требований, превращённые в вызовы. Для сокращателя ссылок:

POST /links        {url}          → {shortCode}
GET  /{shortCode}                 → 302 редирект на url
GET  /links/{shortCode}/stats     → {clicks, ...}

API заставляет встретиться лицом к лицу с разбиением чтение/запись, идемпотентностью и формой ответа — и даёт интервьюеру конкретный контракт, на который давить.

Модель данных. Ключевые сущности (из требований) как таблицы/коллекции с ключами и — главное — ключом партиции/шарда, если шардишь (юнит распределения данных). Ключ шарда — решение по данным с наибольшим рычагом: выбери его под доминирующий паттерн доступа, чтобы частый запрос бил в один шард, и чтобы разнести нагрузку, чтобы ни один шард не был горячим.

links:  short_code (PK)  url  created_at  owner_id        — шард по short_code (точечные lookup)
clicks: short_code  ts  ...   (append-heavy, time-series) — шард по short_code, по бакетам времени

Эти два наброска превращают махающую руками схему коробок в дизайн с реальным контрактом и реальной схемой — и вскрывают сложные части (плохой ключ шарда, отсутствующий индекс, болтливый API) до deep-dive.

Выбор deep-dive: где живёт сложность

Deep-dive — сердце интервью, и выбор того, во что копать, сам по себе сеньорский навык. Выбери компонент, где задача реально сложна — обычно тот, что пометила оценка, или тот, что паттерны доступа сделали неудобным:

• Горячий путь чтения при 300K чтений/с → копни в кэш и стратегию fan-out (юнит кэширования).
• Темп записи за пределом одной primary → копни в схему шардинга и ключ шарда (юнит распределения данных).
• Требование строгой согласованности на распределённой записи → копни в репликацию и обмен CAP/PACELC.
• Fan-out вроде ленты знаменитости → копни в решение fan-out-on-write против fan-out-on-read и гибрид.

Затем иди глубоко: структура данных, режимы отказа, краевые случаи, числа. Deep-dive — где ты показываешь, что реально строил системы: обсуждаешь проблему горячего ключа, thundering herd (шторм одновременных перестроек кэша после истечения TTL) на промахе кэша, стоимость ребаланса при сплите шарда. Объяви выбор вслух («интересная часть — X, я сосредоточусь там»), чтобы интервьюер мог перенаправить, если хотел другой компонент — и чтобы он знал, что ты отличаешь сложную часть от лёгкой.