Введение в системный дизайн

Что такое System Design интервью?

System Design интервью — это этап технического собеседования, где кандидату предлагают спроектировать крупномасштабную систему. Интервьюер оценивает способность кандидата:

• Анализировать требования и задавать правильные вопросы
• Принимать архитектурные решения и обосновывать их
• Понимать компромиссы (trade-offs) между различными подходами
• Проектировать масштабируемые и отказоустойчивые системы

Важно

System Design — обязательный этап на позиции Middle и Senior в большинстве крупных компаний (Google, Meta, Amazon, Яндекс, Тинькофф и др.).

Пошаговый фреймворк

Используйте этот фреймворк для любой задачи на системный дизайн:

┌─────────────────────────────────────────────────────┐
│  1. ТРЕБОВАНИЯ (5 минут)                            │
│     ├── Функциональные требования                   │
│     ├── Нефункциональные требования                 │
│     └── Ограничения и допущения                     │
├─────────────────────────────────────────────────────┤
│  2. ОЦЕНКА НАГРУЗКИ (5 минут)                       │
│     ├── Количество пользователей                    │
│     ├── Запросов в секунду (QPS)                     │
│     ├── Объём хранимых данных                        │
│     └── Пропускная способность сети                  │
├─────────────────────────────────────────────────────┤
│  3. ВЫСОКОУРОВНЕВЫЙ ДИЗАЙН (10 минут)               │
│     ├── Основные компоненты                         │
│     ├── API дизайн                                  │
│     ├── Схема данных                                │
│     └── Архитектурная диаграмма                     │
├─────────────────────────────────────────────────────┤
│  4. ДЕТАЛИЗАЦИЯ (15 минут)                          │
│     ├── Глубокое погружение в ключевые компоненты   │
│     ├── Масштабирование                             │
│     ├── Обработка edge cases                        │
│     └── Оптимизации                                 │
├─────────────────────────────────────────────────────┤
│  5. КОМПРОМИССЫ И ИТОГИ (5 минут)                   │
│     ├── Обсуждение trade-offs                       │
│     ├── Узкие места (bottlenecks)                   │
│     └── Возможные улучшения                         │
└─────────────────────────────────────────────────────┘

Функциональные vs нефункциональные требования

Функциональные требования

Это что система должна делать — конкретные возможности и функции.

Пример системы	Функциональные требования
URL Shortener	Создавать короткие ссылки, перенаправлять по ним, показывать статистику
Мессенджер	Отправлять сообщения, создавать группы, отправлять файлы
Лента новостей	Публиковать посты, подписываться, ставить лайки

Нефункциональные требования

Это как система должна работать — качественные характеристики.

Нефункциональные требования
├── Масштабируемость (Scalability)
│   └── Система должна обслуживать 10M пользователей
├── Доступность (Availability)
│   └── 99.99% uptime (не более 52 минут простоя в год)
├── Производительность (Performance)
│   └── Latency < 200ms для 95-го перцентиля
├── Надёжность (Reliability)
│   └── Данные не должны теряться
├── Консистентность (Consistency)
│   └── Пользователь видит актуальные данные
└── Безопасность (Security)
    └── Шифрование данных, аутентификация

Совет для собеседования

Всегда уточняйте нефункциональные требования! Интервьюер хочет увидеть, что вы понимаете разницу между системой для 1000 и 100 000 000 пользователей.

Оценка нагрузки (Back-of-the-Envelope Estimation)

Умение быстро оценить масштаб системы — важный навык. Вот полезные ориентиры:

Степени двойки

Степень	Приблизительное значение	Название
2^10	1 тысяча	1 KB
2^20	1 миллион	1 MB
2^30	1 миллиард	1 GB
2^40	1 триллион	1 TB

Latency (задержки) — числа, которые должен знать каждый

Операция                          Время
─────────────────────────────────────────────
L1 cache                          1 нс
L2 cache                          4 нс
Оперативная память (RAM)          100 нс
SSD случайное чтение              150 мкс
HDD случайное чтение              10 мс
Сеть (в пределах дата-центра)     0.5 мс
Сеть (между континентами)         150 мс

Пример: оценка для Twitter-подобной системы

Допущения:
- 300M активных пользователей в месяц (MAU)
- 50% заходят ежедневно → 150M DAU
- Каждый пользователь читает 100 твитов в день
- 10% пользователей публикуют 2 твита в день

Чтение:
  150M × 100 = 15B запросов/день
  15B / 86400 ≈ 174 000 QPS (чтение)

Запись:
  15M × 2 = 30M запросов/день
  30M / 86400 ≈ 350 QPS (запись)

Соотношение чтение:запись ≈ 500:1

Хранение (за год):
  30M твитов/день × 365 дней × 300 байт ≈ 3.3 TB текста/год
  + медиа-файлы → значительно больше

Ключевые компоненты распределённых систем

                    ┌──────────┐
                    │  Клиенты │
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │   CDN    │  ← Статический контент
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │ Load     │  ← Балансировка нагрузки
                    │ Balancer │
                    └────┬─────┘
                         │
              ┌──────────┼──────────┐
              │          │          │
         ┌────▼───┐ ┌───▼────┐ ┌──▼─────┐
         │ App    │ │ App    │ │ App    │  ← Серверы приложений
         │ Server │ │ Server │ │ Server │
         └────┬───┘ └───┬────┘ └──┬─────┘
              │         │         │
         ┌────▼─────────▼─────────▼────┐
         │          Cache (Redis)       │  ← Кеш
         └────────────┬────────────────┘
                      │
         ┌────────────▼────────────────┐
         │     Database (Primary)       │  ← Основная БД
         │            │                 │
         │    ┌───────┼───────┐        │
         │    ▼       ▼       ▼        │
         │ Replica  Replica  Replica   │  ← Реплики
         └─────────────────────────────┘

Краткий обзор компонентов

Компонент	Назначение	Примеры
DNS	Преобразование домена в IP	Route 53, Cloudflare DNS
CDN	Раздача статики ближе к пользователю	CloudFront, Akamai
Load Balancer	Распределение нагрузки	Nginx, HAProxy, ALB
API Gateway	Единая точка входа, rate limiting	Kong, AWS API Gateway
Кеш	Быстрый доступ к данным	Redis, Memcached
Очередь сообщений	Асинхронная обработка	Kafka, RabbitMQ, SQS
БД (SQL)	Структурированные данные	PostgreSQL, MySQL
БД (NoSQL)	Неструктурированные данные	MongoDB, Cassandra, DynamoDB
Поиск	Полнотекстовый поиск	Elasticsearch, Solr
Хранилище файлов	Большие файлы, медиа	S3, GCS

Типичные вопросы на собеседовании

1. Спроектируйте URL shortener (bit.ly)
2. Спроектируйте мессенджер (WhatsApp)
3. Спроектируйте ленту новостей (Twitter, Instagram)
4. Спроектируйте систему уведомлений
5. Спроектируйте поисковую систему (Google Search)
6. Спроектируйте облачное хранилище (Google Drive, Dropbox)
7. Спроектируйте видеоплатформу (YouTube)
8. Спроектируйте систему бронирования (Booking.com)

Совет

Не пытайтесь запоминать готовые решения. Вместо этого освойте фреймворк и ключевые строительные блоки (кеш, очереди, БД, балансировщики). Тогда вы сможете спроектировать любую систему.

Рекомендуемые ресурсы

• System Design Interview — Alex Xu (книга, 2 тома)
• Designing Data-Intensive Applications — Martin Kleppmann
• System Design Primer — GitHub (open-source)
• ByteByteGo — визуальные объяснения