System Design Interview

Цели урока

• Знать структуру System Design Interview: clarify, estimate, high-level design, deep dive, trade-offs
• Считать back-of-envelope: QPS, storage, bandwidth за 5 минут, без калькулятора
• Принимать решения по trade-off (CAP, latency vs consistency) и явно их озвучивать
• Описывать классические сценарии: shortener, feed, чат, видеохостинг
• Не молчать: интервьюер оценивает процесс мышления, не финальную картинку

Предварительные знания

• Базовые знания System Design: LB, кэш, БД, очереди
• Понимание CAP-теоремы и распределённых систем хотя бы на уровне ds-01
• Опыт реального бэкенда хотя бы на pet-проекте

В 2012 году Instagram был куплен Facebook за $1 млрд. На момент покупки сервисом пользовались 30 млн человек, а команда инженеров состояла из 13 человек. Как 13 человек обслуживали 30 миллионов? Правильные архитектурные решения с первого дня.

• **Meta** проводит System Design Interview как обязательный этап для всех инженеров E4+. Типичная задача: спроектировать Facebook News Feed для 1 млрд пользователей за 45 минут
• **Google** оценивает не только решение, но и сам процесс: как уточняются требования, как обосновываются выборы - правильный process важнее правильного ответа
• **Uber** на System Design спрашивает про их реальные системы: surge pricing, matching водителей, геозапросы - используется реальный production context как основа задания

Load Balancer

**Load Balancer** распределяет трафик между несколькими экземплярами сервиса, обеспечивая горизонтальное масштабирование и fault tolerance. В System Design Interview вопрос "как масштабируешь до миллионов пользователей" почти всегда включает LB как первый шаг.

На интервью нужно различать L4 и L7 балансировщики: **L4** работает быстрее (не смотрит на HTTP-контент), **L7** позволяет routing по пути (`/api` → сервис A, `/static` → CDN), A/B тестирование по заголовкам, SSL termination. Для большинства веб-приложений нужен L7.

Критическая точка отказа (SPOF): сам LB. Решение - Active-Passive пара (keepalived + Virtual IP) или Active-Active через anycast DNS. Facebook использует ECMP routing - несколько равнозначных маршрутов до датацентров, балансировка происходит на уровне маршрутизаторов.

Database Design

Выбор базы данных - один из ключевых трейдоффов в System Design. Нет "лучшей" базы - есть подходящая для конкретного access pattern'а. На интервью нужно уметь обосновывать выбор, а не просто называть технологию.

**CAP теорема** на интервью: при network partition система выбирает между Consistency и Availability. PostgreSQL/MySQL - CP (данные всегда консистентны, но при failover есть downtime). Cassandra/DynamoDB - AP (всегда доступны, но может быть stale data). Для финансовых систем - CP. Для социальных лент - AP.

Instagram хранит метаданные фото в PostgreSQL (sharded), сами файлы в S3, поисковый индекс в Elasticsearch. Twitter использует три базы одновременно: MySQL для user data, Redis для timeline cache, Manhattan (собственная Cassandra-based) для твитов. Правильный ответ на интервью - полигот persistence.

Caching Strategy

Кэширование - самый быстрый способ масштабировать систему: правильно настроенный Redis уменьшает нагрузку на БД на 80-95%. На System Design Interview нужно объяснить не только "добавить Redis", но и какую стратегию инвалидации использовать.

**Cache eviction policies:** LRU (Least Recently Used) - выгружает давно не использованные ключи, подходит для hot spot данных. LFU (Least Frequently Used) - выгружает редко запрашиваемые, лучше для стабильных паттернов. TTL - принудительное устаревание через время. Twitter использует комбинацию: LRU для user timelines + TTL для API responses.

YouTube кэширует видео-манифесты и thumbnail'ы на CDN (Akamai) - 95% трафика обслуживается без origin-сервера. Netflix использует Open Connect Appliances - физические серверы в датацентрах ISP с локальным кэшем популярного контента. Принцип тот же: данные максимально близко к пользователю.

Tradeoffs в System Design

Главное, что оценивают на System Design Interview - умение осознанно выбирать между альтернативами. Правильный ответ - не "лучший" паттерн, а паттерн, который подходит для **конкретных требований** с объяснением что именно пожертвовано.

Числа, которые стоит знать для System Design: HDD sequential read ~150 MB/s, SSD ~500 MB/s, RAM ~10 GB/s, L1 cache ~1 ns, RAM доступ ~100 ns, SSD ~100 мкс, HDD ~10 мс, сеть в датацентре ~0.5 мс, cross-region ~150 мс. Эти числа помогают обосновывать выбор - "Redis в памяти быстрее PostgreSQL на SSD в 1000 раз".

Структура ответа на System Design Interview: 1) **Clarify requirements** - DAU, QPS, объём данных, SLA. 2) **High-level design** - основные блоки системы. 3) **Deep dive** - критические компоненты детально. 4) **Bottlenecks & scaling** - где узкие места, как масштабировать. 5) **Tradeoffs** - что выбрано и почему.

Итоги

• **Load Balancer** - первый шаг масштабирования: L4 для скорости, L7 для HTTP-routing; LB сам является SPOF - нужна HA-пара или anycast
• **Database Design** - полигот persistence: PostgreSQL для транзакций, Redis для кэша/сессий, Cassandra для write-heavy time-series, Elasticsearch для поиска
• **Caching** - Cache-Aside как default стратегия; инвалидация сложнее чем кажется; Cache Stampede решается mutex lock или probabilistic early expiration
• **Tradeoffs** - единственно правильный ответ на интервью: собрать требования → предложить решение → явно назвать что пожертвовано и почему это приемлемо

Связанные темы

System Design собирает все знания по архитектуре в единое целое:

• Масштабирование систем — Горизонтальное масштабирование, HPA, readiness probes - практические детали которые нужны в System Design
• Монолит vs Микросервисы — Ключевой трейдофф на интервью: когда микросервисы оправданы по масштабу, а когда модульный монолит лучше
• Observability — Спроектированная система должна быть observable - метрики, логи, трейсинг как часть дизайна

Вопросы для размышления

• Какую систему из повседневного использования (YouTube, Instagram, WhatsApp) интереснее всего было бы спроектировать? С чего начать сбор требований?
• Какой из трейдоффов (consistency vs availability, read vs write optimization, cost vs performance) наиболее актуален для системы, с которой работает команда прямо сейчас?
• Если завтра нагрузка вырастет в 10 раз - какое место в текущей архитектуре сломается первым?

Связанные уроки

• sd-01-intro