Топ-10 задач по System Design для собеседований: подробные разборы и архитектурные решения

Введение: эволюция System Design интервью в 2026 году

Проектирование систем перестало быть теоретическим упражнением по рисованию стрелок между балансировщиком и базой данных. Сегодня интервьюер ожидает, что кандидат понимает экономику облачных ресурсов, умеет работать с векторными базами данных для LLM-сервисов и знает, как обеспечить консистентность в условиях глобально распределенных дата-центров. Эта статья предназначена для Senior и Staff инженеров, которые готовятся к техническим секциям в компаниях уровня Tier-1.

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

Для кого этот материал

Статья будет полезна бэкенд-разработчикам, системным архитекторам и лидам, стремящимся систематизировать знания. Мы не просто описываем «как это работает», а анализируем, почему выбирается то или иное решение в условиях ограниченных ресурсов и жестких требований к SLA (Service Level Agreement). Вы узнаете, как отвечать на уточняющие вопросы интервьюера и как правильно проводить декомпозицию неопределенных требований в четкую техническую спецификацию.

1. Проектирование мессенджера масштаба WhatsApp

Задача проектирования мессенджера в 2026 году усложняется требованиями к сквозному шифрованию (E2EE) по умолчанию и поддержке мультидевайсности. Основная сложность здесь — поддержка сотен миллионов постоянных соединений и мгновенная доставка сообщений при нестабильном интернете. Нам нужно обеспечить доставку статусов (прочитано/доставлено), передачу медиафайлов и синхронизацию истории между устройствами пользователя.

Оценка нагрузки и хранилища

Предположим, у нас 500 млн DAU. Каждый пользователь отправляет в среднем 40 сообщений в день. Это дает нам 20 млрд сообщений в сутки. При среднем размере сообщения в 100 байт, нам потребуется около 2 ТБ дискового пространства ежедневно только для текста. Пиковая нагрузка может достигать 500 000 RPS на запись. Для управления соединениями мы будем использовать WebSocket или gRPC потоки, что требует значительных ресурсов оперативной памяти на серверах шлюзов (Gateway).

Архитектурные компоненты

Ключевым компонентом является сервис сессий (Session Service), который хранит информацию о том, на каком сервере находится активное соединение конкретного пользователя. В 2026 году для этих целей оптимально использовать Redis с поддержкой Cluster Mode или аналогичные in-memory решения с минимальной задержкой. Для хранения сообщений лучше всего подходит NoSQL база данных типа Cassandra или ScyllaDB из-за их способности к линейному масштабированию записи и эффективному хранению временных рядов (time-series data).

2. Система сокращения ссылок (URL Shortener)

Хотя задача кажется простой, на уровне системного дизайна она проверяет умение работать с кэшированием, генерацией уникальных ID и перенаправлением трафика. Основной вызов — обеспечить минимальную задержку (latency) при чтении, так как пользователи ожидают мгновенного редиректа. Также необходимо учитывать механизмы защиты от спама и аналитику переходов в реальном времени.

Генерация коротких ключей

Мы можем использовать Base62 кодирование (a-z, A-Z, 0-9). Семь символов дают нам 62^7 ≈ 3.5 триллиона комбинаций, чего достаточно на десятилетия работы. Для генерации ID нельзя использовать автоинкремент в SQL, так как это станет узким местом. Вместо этого применяется распределенный генератор ID, такой как Snowflake (от Twitter) или предварительная генерация диапазонов (Range Handler) в ZooKeeper/Etcd.

Кэширование и производительность

Поскольку 80% трафика обычно приходится на 20% популярных ссылок (закон Парето), агрессивное кэширование в Redis критически важно. Мы должны использовать политику вытеснения LFU (Least Frequently Used) или LRU. При запросе короткой ссылки система сначала проверяет кэш, и только при промахе идет в основную базу (например, MongoDB или DynamoDB). Для глобального покрытия целесообразно использовать CDN для статических редиректов популярных ссылок на границе сети (Edge).

3. Проектирование ленты новостей (News Feed)

Проектирование ленты (Facebook, Instagram, Twitter) — это классическая задача на выбор между Pull и Push моделями обновлений. В 2026 году к этому добавляется персонализация на основе ML-ранжирования в реальном времени. Нам нужно решить, как эффективно доставлять контент от «знаменитостей» (миллионы подписчиков) и обычных пользователей.

Fan-out стратегии

Для обычных пользователей используется модель Push: при публикации пост записывается в кэши (Timeline) всех друзей. Это обеспечивает быстрое чтение. Однако для пользователей с миллионами подписчиков (Celebrities) модель Push вызовет лавинообразную нагрузку на систему. Для них применяется модель Pull: пост записывается только в одну корзину автора, а подписчики запрашивают его при обновлении своей ленты. Гибридный подход позволяет сбалансировать нагрузку на запись и чтение.

Ранжирование и фильтрация

Лента не просто показывает посты в хронологическом порядке. Сервис ранжирования (Ranking Service) использует признаки: интересы пользователя, свежесть контента, тип медиа. В современной архитектуре это реализуется через двухэтапный процесс: сначала быстрый отбор (Candidate Generation) топ-1000 постов из кэша, затем детальное ранжирование тяжелой моделью ML. Данные для признаков хранятся в графовых базах данных (например, Neo4j) для быстрого обхода социальных связей.

4. Глобальный сервис такси (Uber/Lyft)

Здесь фокус смещается на геораспределенные данные и обработку потоков координат в реальном времени. Основная проблема — поиск ближайших водителей (Geospatial Queries) и динамическое ценообразование (Surge Pricing) в зависимости от спроса и предложения в конкретном квадрате города.

Гео-индексация

Для эффективного поиска нельзя просто делать `SELECT * WHERE distance < 1km`. Мы используем пространственные индексы: Quadtrees, Google S2 Geometry или Uber H3. Эти библиотеки разбивают карту мира на иерархические ячейки (шестиугольники или квадраты). Координаты водителей обновляются каждые 3-5 секунд и хранятся в Redis с использованием Geospatial индексов (GEOADD/GEORADIUS), что позволяет находить объекты за константное время.

Распределенные транзакции и консистентность

Когда водитель принимает заказ, нам нужно гарантировать, что этот заказ не будет отдан кому-то другому. Это требует атомарности. В распределенной среде мы используем паттерн Saga для управления длительными бизнес-процессами (поиск водителя -> ожидание ответа -> оплата -> поездка). Если на каком-то этапе происходит сбой (например, карта не прошла), запускаются компенсирующие транзакции для отмены бронирования.

5. Видеохостинг (YouTube/Netflix)

Проектирование видеохостинга требует понимания процессов транскодирования, хранения петабайт данных и работы сетей доставки контента (CDN). Основная задача — обеспечить бесперебойное воспроизведение в разных разрешениях при любой скорости интернета (Adaptive Bitrate Streaming).

Конвейер обработки видео

Загруженное видео должно быть разбито на чанки по 2-5 секунд и перекодировано в десятки форматов (H.264, VP9, AV1) и разрешений (от 144p до 8K). Этот процесс крайне ресурсоемок. Мы используем очередь задач (RabbitMQ/Kafka) и парк воркеров на GPU. Метаданные хранятся в SQL (PostgreSQL), а сами файлы — в объектных хранилищах (S3), которые интегрированы с CDN для кеширования контента максимально близко к конечному пользователю.

Оптимизация доставки

Netflix разработал собственную сеть Open Connect, устанавливая свои сервера прямо внутри узлов интернет-провайдеров (ISP). При проектировании системы на интервью важно упомянуть алгоритмы выбора ближайшего узла CDN на основе BGP-маршрутов или задержки (latency-based routing). Также стоит обсудить предиктивное кэширование: если сериал популярен в конкретном регионе, его нужно заранее «прогреть» на локальных серверах до официального релиза.

6. Проектирование API Rate Limiter

Rate Limiter — это критический компонент для защиты сервисов от перегрузки и DoS-атак. На интервью часто просят реализовать его как отдельный микросервис или middleware. Нужно обсудить алгоритмы и способы хранения счетчиков в распределенной системе.

Алгоритмы ограничения

• Token Bucket: Позволяет кратковременные всплески трафика. Токены пополняются с фиксированной скоростью.
• Leaky Bucket: Запросы обрабатываются с постоянной скоростью, излишки отбрасываются. Подходит для выравнивания нагрузки.
• Fixed Window Counter: Простой, но имеет проблему «границы окна», когда в стыке двух минут может пройти двойная норма запросов.
• Sliding Window Logs/Counters: Самый точный, но требует больше памяти для хранения меток времени каждого запроса.

Распределенная реализация

Для работы в кластере счетчики должны храниться в централизованном хранилище, например, в Redis. Однако обращение к Redis на каждый запрос создает накладные расходы. Оптимизация заключается в использовании локального кэша в памяти приложения с периодической синхронизацией (Batching) или использовании алгоритма Generic Cell Rate Algorithm (GCRA). Также важно обсудить стратегию действий при превышении лимита: возврат HTTP 429 Too Many Requests с заголовком Retry-After.

7. Веб-индексатор (Web Crawler)

Задача проектирования поискового робота проверяет навыки работы с графами, очередями приоритетов и вежливым сканированием (Politeness Policy). Система должна обходить миллиарды страниц, избегать «ловушек» для ботов и эффективно обновлять индекс.

Компоненты системы

Центральный элемент — URL Frontier, очередь ссылок, которые нужно посетить. Она должна учитывать приоритет (PageRank страницы) и частоту обновлений. Чтобы не перегружать целевые сайты, мы используем хэширование по домену, направляя все ссылки с одного сайта на один и тот же воркер с задержкой между запросами. Для исключения дубликатов контента применяются алгоритмы шифрования (SimHash или MinHash), которые позволяют находить «почти одинаковые» страницы.

Хранение данных

Результаты сканирования (текст, метаданные) сохраняются в документоориентированные базы данных. Для полнотекстового поиска в 2026 году стандартом является использование инвертированного индекса (Elasticsearch/Solr) в сочетании с векторными представлениями (Embeddings), хранящимися в специализированных базах типа Milvus или Pinecone. Это позволяет выполнять семантический поиск, а не просто поиск по ключевым словам.

8. Проектирование распределенного кэша (типа Redis)

В этой задаче интервьюер хочет увидеть ваше понимание сетевых протоколов, управления памятью и структур данных. Как обеспечить низкую задержку и высокую доступность? Как реализовать репликацию данных между узлами?

Архитектура памяти

Кэш должен работать полностью в RAM. Для эффективного использования памяти применяются специальные структуры данных: Skip Lists для ранжированных списков, хэш-таблицы с открытой адресацией. Важно обсудить механизмы вытеснения данных (Eviction Policies), такие как LRU (Least Recently Used) или LFU. В 2026 году актуально обсуждение использования Tiered Storage, когда горячие данные лежат в RAM, а менее востребованные — на быстрых NVMe дисках.

Консистентность и доступность

Для обеспечения отказоустойчивости используется репликация (Master-Slave). Для автоматического переключения при сбоях (Failover) применяется протокол консенсуса Raft или Paxos. Если система должна быть глобально распределенной, возникает вопрос синхронизации между регионами. Здесь вступают в игру CRDT (Conflict-free Replicated Data Types), которые позволяют обновлять данные в разных местах без блокировок и гарантируют итоговую сходимость (Eventual Consistency).

9. Система мониторинга и метрик (Prometheus/Datadog)

Системы мониторинга обрабатывают огромные потоки данных временных рядов (Time Series). Основной вызов — высокая скорость записи и необходимость выполнения агрегационных запросов (например, среднее значение CPU за час) в реальном времени.

Хранение временных рядов (TSDB)

Данные метрик — это кортежи (timestamp, value) с набором тегов. Обычные реляционные БД плохо справляются с такой нагрузкой. Мы используем специализированные TSDB (InfluxDB, VictoriaMetrics, ClickHouse). Ключевая оптимизация — сжатие данных (Delta-encoding, Gorilla compression), которое позволяет уменьшить объем хранимых данных в 10 раз. Данные группируются по блокам времени, что ускоряет чтение диапазонов.

Сбор данных: Push vs Pull

Нужно обосновать выбор модели сбора. Prometheus использует Pull (сервер опрашивает агентов), что упрощает контроль нагрузки на сервер мониторинга. Datadog использует Push (агенты отправляют данные), что лучше подходит для динамических сред (Serverless, контейнеры с коротким циклом жизни). В крупных системах часто используется гибридный подход с промежуточными агрегаторами (StatsD), которые собирают метрики локально и отправляют их пачками.

10. Проектирование облачного хранилища (Dropbox/Google Drive)

Эта задача фокусируется на синхронизации файлов, дедупликации и обеспечении надежности данных (Durability). Как эффективно передавать большие файлы и обрабатывать конфликты версий, когда два пользователя редактируют один документ одновременно?

Синхронизация и дедупликация

Вместо передачи файла целиком, мы разбиваем его на блоки (chunks) фиксированного или переменного размера. Если два пользователя загружают одинаковый файл, мы храним его только один раз (Deduplication), экономя петабайты пространства. Для отслеживания изменений используется Metadata Database (SQL), где хранятся версии файлов и их привязка к блокам. Клиентские приложения используют алгоритм дифференциальной синхронизации (rsync-like), передавая только измененные блоки.

Надежность и доступность

Для обеспечения сохранности данных при выходе из строя целых дата-центров используется Erasure Coding (избыточное кодирование) вместо простого реплицирования. Это позволяет восстановить данные при потере части блоков с меньшими затратами памяти, чем при тройной репликации. Консистентность метаданных обеспечивается строгими транзакциями в БД, в то время как сами данные в объектном хранилище могут быть доступны с небольшой задержкой (Eventual Consistency).

Заключение: чек-лист подготовки к System Design

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

План действий для кандидата

• Изучите современные облачные примитивы (Managed Kafka, Serverless, Vector DB).
• Потренируйтесь в Capacity Estimation: вы должны быстро считать в уме, сколько серверов нужно для 100k RPS.
• Разберитесь в компромиссах: Latency vs Throughput, Consistency vs Availability (CAP теорема).
• Посмотрите реальные архитектуры крупных компаний (Netflix Tech Blog, Engineering at Meta).

Помните, что интервьюер — это ваш «коллега», с которым вы обсуждаете проект. Будьте готовы к критике и предлагайте альтернативные варианты решения проблем.