Учебная платформа AST-STUDY

← Назад к курсу

Основы System Design

1. Что такое System Design?

System Design — процесс проектирования архитектуры, компонентов, модулей, интерфейсов и данных системы для удовлетворения конкретных требований. Цель — создать масштабируемую, надежную, эффективную и поддерживаемую систему.

2. Ключевые понятия и определения

Масштабируемость (Scalability)

Способность системы обрабатывать увеличение нагрузки путем добавления ресурсов.

  • Вертикальное масштабирование (Scale Up): Увеличение мощности существующего сервера (CPU, RAM).
  • Горизонтальное масштабирование (Scale Out): Добавление большего количества серверов.

Надежность (Reliability)

Способность системы работать без сбоев в течение определенного времени. Измеряется в процентах доступности (99.9%, 99.99% и т.д.).

Доступность (Availability)

Процент времени, когда система работает.

  • 99.9% (three-nines) = 8.76 часов простоя в год
  • 99.99% (four-nines) = 52.6 минут простоя в год
  • 99.999% (five-nines) = 5.26 минут простоя в год

Производительность (Performance)

  • Latency (задержка): Время выполнения одной операции
  • Throughput (пропускная способность): Количество операций в единицу времени
  • Concurrent Users (одновременные пользователи): Пользователи, активно взаимодействующие с системой

Эффективность использования ресурсов (Efficiency)

  • CPU utilization
  • Memory usage
  • Network bandwidth

Управление состоянием (State Management)

  • Stateless (без состояния): Каждый запрос независим, не требует сохранения состояния между запросами
  • Stateful (с состоянием): Сервер хранит информацию о состоянии клиента между запросами

3. Расчет нагрузки и метрики

Базовые формулы для оценки:

  1. Оценка пользователей:

    Всего пользователей = X
Daily Active Users (DAU) = Всего пользователей × % активных ежедневно
Concurrent Users = DAU × % одновременных / 24 часа

  2. Расчет запросов:

    QPS (Queries Per Second) = (Запросов в день) / (86400 секунд в день)
RPS (Requests Per Second) = (Всего запросов) / (секунд в периоде)

  3. Объем данных:

    Хранилище в день = (Записей в день) × (Размер одной записи)
Трафик в день = (Запросов в день) × (Средний размер ответа)

Пример расчета для приложения:

Предположим:
- 10 млн пользователей
- 20% DAU = 2 млн активных пользователей в день
- Пиковая нагрузка: 5% одновременных = 100k concurrent users
- Каждый пользователь делает 10 запросов в час
- Пиковый QPS = (100k × 10) / 3600 ≈ 278 запросов/сек

4. Основные компоненты архитектуры

Load Balancer

Распределяет трафик между серверами. Типы:

  • Round Robin
  • Least Connections
  • IP Hash
  • Географический

Кэширование (Caching)

  • CDN: Для статического контента
  • In-memory cache: Redis, Memcached
  • Кэширование на клиенте
  • Кэширование в базе данных

Стратегии инвалидации кэша:

  • TTL (Time To Live)
  • Write-through
  • Write-behind
  • Cache-aside (Lazy Loading)

Базы данных

  • SQL (реляционные): MySQL, PostgreSQL — для структурированных данных, транзакций
  • NoSQL:
    • Документные (MongoDB)
    • Ключ-значение (Redis)
    • Колоночные (Cassandra)
    • Графовые (Neo4j)

Очереди сообщений (Message Queues)

Для асинхронной обработки, буферизации.

  • RabbitMQ, Kafka, SQS

Микросервисы vs Монолит

  • Монолит: Простота разработки, но сложность масштабирования
  • Микросервисы: Гибкость, независимое масштабирование, но сложность управления

5. CAP-теорема

Система может гарантировать только 2 из 3 свойств:

  1. Consistency (согласованность): Все узлы видят одинаковые данные в один момент времени
  2. Availability (доступность): Каждый запрос получает ответ (успех или ошибка)
  3. Partition Tolerance (устойчивость к разделению): Система работает при сетевых сбоях

Частые комбинации:

  • CP: Банковские системы (согласованность важнее доступности)
  • AP: Социальные сети (доступность важнее мгновенной согласованности)

6. Паттерны проектирования

Репликация (Replication)

  • Master-Slave: Чтение из slave, запись в master
  • Master-Master: Запись в любой узел

Шардирование (Sharding/Partitioning)

Разделение данных между разными серверами:

  • Горизонтальное: Разные строки в разных БД
  • Вертикальное: Разные колонки в разных БД

Стратегии шардирования:

  • По диапазону (range-based)
  • По хэшу (hash-based)
  • По списку (list-based)
  • По географическому признаку

Резервирование (Redundancy)

Дублирование компонентов для повышения надежности.

7. Протоколы и API

REST

  • Стандартный HTTP
  • Stateless
  • Ресурсо-ориентированный

GraphQL

  • Гибкие запросы
  • Единственная конечная точка
  • Клиент определяет структуру ответа

gRPC

  • Высокая производительность
  • Использует Protocol Buffers
  • Поддержка потоковой передачи

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

Примеры заданий:

  1. "Спроектируйте систему типа TinyURL"
  2. "Как бы вы построили Instagram/Twitter?"
  3. "Спроектируйте систему рекомендаций"
  4. "Спроектируйте Uber/Lyft"
  5. "Как бы вы масштабировали чат?"

Общий подход к решению:

  1. Уточнение требований:

    • Функциональные требования
    • Нефункциональные требования
    • Ограничения

  2. Оценка масштаба:

    • Количество пользователей
    • Трафик, объем данных
    • Рост системы

  3. Проектирование высокоуровневой архитектуры:

    • Компоненты и их взаимодействие
    • Выбор технологий

  4. Детализация:

    • Схема данных
    • API design
    • Алгоритмы

  5. Анализ проблем:

    • Узкие места
    • Масштабируемость
    • Надежность
    • Безопасность

  6. Оптимизация:

    • Кэширование
    • Асинхронная обработка
    • Репликация

9. Практические советы для собеседования

  1. Всегда начинайте с уточнения требований
  2. Делайте оценки "на салфетке" — покажите, как считаете
  3. Рисуйте диаграммы — клиенты, LB, сервера, БД, кэш
  4. Объясняйте trade-offs — почему выбираете тот или иной подход
  5. Говорите о масштабировании — что делать при 10x, 100x нагрузке
  6. Не забывайте про мониторинг и логирование
  7. Упомяните security — аутентификация, авторизация, DDOS защита
  8. Будьте готовы к follow-up вопросам

10. Инструменты и технологии (для упоминания)

Облачные платформы:

  • AWS, Google Cloud, Azure

Контейнеризация и оркестрация:

  • Docker, Kubernetes

Мониторинг:

  • Prometheus, Grafana, ELK Stack

CI/CD:

  • Jenkins, GitLab CI, GitHub Actions

Ключевой вывод: System Design — это поиск баланса между различными требованиями и ограничениями. На собеседовании важнее показать ход мыслей и умение принимать взвешенные решения, чем дать единственно правильный ответ.