Самые частые задачи System Design на собеседовании с разбором

Введение в современный System Design

К 2026 году проектирование систем перестало быть просто упражнением по выбору между SQL и NoSQL. Сегодня архитекторы сталкиваются с необходимостью интеграции LLM-агентов, обработки петабайтов данных в реальном времени и обеспечения доступности на уровне 99.999% в условиях фрагментированного облачного рынка. Подготовка к System Design интервью требует не только знания базовых паттернов вроде шардирования или кеширования, но и понимания того, как эти элементы взаимодействуют в распределенной среде под экстремальной нагрузкой.

Эта статья написана для инженеров уровней Middle+, Senior и Lead, которые планируют проходить интервью в компании уровня FAANG или крупные локальные экосистемы. Мы разберем задачи, которые стали стандартом индустрии, и добавим к ним актуальные требования 2026 года: от энергоэффективности дата-центров до соблюдения жестких протоколов приватности данных. Вы узнаете, как структурировать свой ответ, на каких цифрах делать акцент и какие компромиссы (trade-offs) сейчас ценятся работодателями больше всего.

Почему System Design важен в 2026 году

С развитием серверлесс-архитектур и автоматизированного масштабирования может показаться, что проектирование систем упростилось. Однако реальность обратная: сложность перешла на уровень оркестрации и управления состоянием. Компании ищут людей, способных предсказать точки отказа системы до того, как будет написана первая строка кода. Ошибка в дизайне на этапе планирования в 2026 году стоит в десятки раз дороже, чем пять лет назад, из-за огромной связности сервисов.

Что вы узнаете из этого лонгрида

Мы пройдем путь от оценки ресурсов (back-of-the-envelope estimation) до детального проектирования API и выбора стратегий репликации. В каждой секции будет представлен разбор конкретной задачи с учетом современных технологий: gRPC-web, векторных баз данных и распределенных транзакций в мультиоблачных средах.

1. Проектирование системы сокращения ссылок (URL Shortener)

Это классическая задача, которая в 2026 году обросла новыми деталями, связанными с аналитикой в реальном времени и защитой от фишинга. Нам нужно спроектировать сервис, который принимает длинный URL и возвращает короткий идентификатор. Основная нагрузка здесь идет на чтение, так как по одной созданной ссылке могут переходить миллионы раз.

Оценка масштаба и требований

Допустим, наша система обрабатывает 100 миллионов новых ссылок в месяц. При соотношении чтений к записи 100:1, мы получаем 10 миллиардов переходов. Если мы храним ссылки 10 лет, нам нужно место для 12 миллиардов записей. При среднем размере записи в 500 байт (URL + метаданные + аналитика), общий объем данных составит около 6 ТБ. Это вполне умещается в одну современную распределенную БД, но требует грамотного индексирования.

Выбор алгоритма генерации ID

В 2026 году использование простого автоинкремента в БД считается плохим тоном из-за предсказуемости и проблем с шардированием. Мы выбираем Base62 кодирование (a-z, A-Z, 0-9). Для 12 миллиардов записей нам достаточно 7 символов (62^7 ≈ 3.5 триллиона комбинаций). Для генерации мы можем использовать распределенный сервис генерации ID (например, на базе Snowflake ID), чтобы избежать коллизий без обращения к центральной БД.

2. Дизайн мессенджера типа WhatsApp или Telegram

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

Управление соединениями и WebSocket

Для мгновенной доставки сообщений мы используем WebSocket. В 2026 году стандартным подходом является использование Edge-нод, разбросанных географически. Пользователь подключается к ближайшей ноде, которая поддерживает сессию. Если получатель онлайн, сообщение пересылается через шину данных (например, NATS или Kafka) на соответствующую Edge-ноду получателя.

Хранение истории и консистентность

Для хранения сообщений идеально подходит ширококолоночная база данных (Wide-column store). Сообщения группируются по `chat_id`. Важно обеспечить очередность доставки. Мы используем логические часы (Lamport timestamps) или Vector Clocks, чтобы корректно отображать сообщения, отправленные почти одновременно с разных устройств.

Чек-лист для мессенджера

• Поддержка статуса «в сети» (Presence service) через Heartbeat-механизм.
• Многоуровневое хранение: горячие данные в оперативной памяти, архив в холодном хранилище.
• Обработка медиафайлов через S3-совместимые хранилища с CDN.
• Push-уведомления как резервный канал доставки.

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

Задача News Feed (как в X или VK) в 2026 году фокусируется на персонализации с помощью AI-ранжирования в реальном времени. Нам нужно не просто показать посты друзей, а отфильтровать их через модель предпочтений пользователя, учитывая тысячи сигналов.

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

Основная проблема — доставка поста популярного пользователя (селебрити) миллионам подписчиков. Мы используем гибридный подход. Для обычных пользователей применяется Push-модель (запись в кеши подписчиков при публикации). Для «звезд» — Pull-модель (подписчики запрашивают обновления при входе). Это предотвращает лавинообразную нагрузку на систему при каждом посте известной личности.

Архитектура ранжирования

В 2026 году лента не может быть просто хронологической. Мы внедряем сервис ранжирования, который запрашивает векторные представления (embeddings) пользователя и последних постов. Используется двухэтапная схема: сначала быстрая выборка (Candidate Generation) топ-500 постов, затем тяжелое ранжирование нейросетью топ-50 постов, которые увидит пользователь.

Ключевые метрики дизайна

• Latency: лента должна грузиться менее чем за 200 мс.
• Доступность: даже при отказе сервиса ранжирования пользователь должен увидеть кешированную или хронологическую ленту.
• Масштабируемость: поддержка до 1 млн запросов в секунду (RPS).

4. Дизайн видеохостинга (YouTube/Netflix)

В 2026 году проектирование видеохостинга включает поддержку 8K контента и адаптивного стриминга (ABR) с минимальной задержкой. Основной упор делается на эффективное хранение и транскодирование петабайтов данных.

Конвейер загрузки и транскодирования

Когда пользователь загружает видео, оно разбивается на чанки. Это позволяет распараллелить процесс транскодирования в разные форматы (H.265, AV1) и разрешения. Мы используем распределенную очередь задач (Temporal или самописное решение на Kafka), чтобы управлять рабочими узлами транскодера.

Content Delivery Network (CDN)

Для раздачи контента критически важно использовать многоуровневый CDN. Популярные видео (тренды) кешируются на L1-узлах провайдеров (ISP), менее популярные — на региональных L2-узлах. В 2026 году также активно применяется Peer-to-Peer (P2P) стриминг между клиентами в одной локальной сети для снижения нагрузки на магистральные каналы.

Таблица стратегий хранения

5. Проектирование системы вызова такси (Uber/Lyft)

Главная сложность этой задачи — работа с геоданными, которые меняются каждую секунду. В 2026 году к этому добавляется динамическое ценообразование (Surge Pricing) на основе предсказательных моделей спроса.

Гео-индексация в реальном времени

Для поиска ближайших водителей мы не можем использовать обычные SQL-запросы. Мы применяем Google S2 Geometry или Uber H3 (гексагональная сетка). Вся карта мира разбивается на ячейки. Текущие координаты водителей хранятся в Redis (используя Redis Geo) или специализированных базах типа Tile38. Обновление позиции происходит каждые 2-3 секунды.

Matching Service (Сервис сопоставления)

Когда пассажир нажимает кнопку, система должна найти оптимального водителя. Это не всегда ближайший по прямой. Мы учитываем дорожную ситуацию, рейтинг и вероятность того, что водитель отменит заказ. Алгоритм работает в контексте транзакции: мы «бронируем» водителя на 15 секунд, пока он принимает решение.

Основные компоненты системы

• Supply Service: отслеживает состояние водителей (свободен, занят, перерыв).
• Demand Service: анализирует входящие заказы.
• Pricing Engine: рассчитывает стоимость поездки с учетом пробок и погоды.
• Payment Gateway: интеграция с внешними платежными системами.

6. Дизайн поисковой системы (Web Crawler & Indexer)

Поиск в 2026 году — это не только индексация текста, но и понимание семантики через эмбеддинги. Задача разбивается на две части: обход веба (Crawling) и построение инвертированного индекса.

Масштабируемый Crawler

Нам нужна система, которая обходит миллиарды страниц, соблюдая вежливость (Robots.txt) и приоритеты. Мы используем распределенную очередь URL, где приоритет страницы вычисляется на основе PageRank или частоты обновлений. Для хранения слепков страниц (snapshots) используются объектные хранилища с дедупликацией.

Инвертированный индекс и векторный поиск

Классический инвертированный индекс (слово -> список документов) дополняется векторным индексом (FAISS или Milvus). Это позволяет искать не только по ключевым словам, но и по смыслу. Индекс шардируется по Document ID, чтобы запросы можно было выполнять параллельно на сотнях серверов.

Схема обработки запроса

1. Query Rewrite: исправление опечаток, расширение синонимами.
2. Retrieval: получение кандидатов из инвертированного и векторного индексов.
3. Ranking: применение модели ранжирования (LambdaMART или трансформеры).
4. Snippet Generation: формирование краткого описания страницы.

7. Проектирование системы мониторинга и алертинга

В 2026 году системы мониторинга (аналоги Prometheus/Grafana) должны обрабатывать триллионы метрик в секунду (High Cardinality) от миллионов контейнеров и микросервисов.

Time Series Database (TSDB)

Данные метрик — это временные ряды. Мы используем специализированные БД (VictoriaMetrics или InfluxDB). Основной вызов — хранение меток (labels). Если у нас есть метка `pod_id`, их количество может быть огромным. Мы применяем инвертированные индексы для тегов и агрегацию данных «на лету» (downsampling) для старых записей.

Push vs Pull модель

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

Чек-лист по алертингу

• Дедупликация алертов: не слать 100 уведомлений, если упал один коммутатор.
• Иерархия зависимостей: понимать, что сервис упал, потому что упала БД.
• Интеграция с инцидент-менеджментом (PagerDuty, Opsgenie).

8. Дизайн распределенного кеша (Redis/Memcached)

На интервью часто просят спроектировать не использование кеша, а сам кеш как сервис. В 2026 году акцент делается на консистентности в мультирегиональных инсталляциях.

Алгоритмы вытеснения (Eviction Policies)

Кроме классического LRU (Least Recently Used), мы обсуждаем LFU (Least Frequently Used) и современные адаптивные алгоритмы (например, ARC). Важно объяснить, как реализовать LRU эффективно с помощью Hash Map и Doubly Linked List (сложность O(1) на чтение и запись).

Консистентное хеширование (Consistent Hashing)

Чтобы масштабировать кеш на несколько узлов, мы используем консистентное хеширование. Это минимизирует перераспределение ключей при добавлении или удалении ноды. В 2026 году стандартным является использование виртуальных узлов для более равномерного распределения нагрузки между физическими серверами.

Репликация и надежность

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

Rate Limiter необходим для защиты системы от перегрузок и DoS-атак. В 2026 году это часто реализуется на уровне API Gateway или Service Mesh (Istio/Linkerd).

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

1. Token Bucket: позволяет кратковременные всплески трафика.
2. Leaky Bucket: обеспечивает строго равномерную скорость обработки.
3. Fixed Window Counter: прост, но имеет проблему всплесков на границе окон.
4. Sliding Window Log/Counter: самый точный, но требует больше памяти.

Распределенный Rate Limiter

Если у нас много инстансов API, нам нужно общее хранилище для счетчиков. Мы используем Redis с операциями INCR и EXPIRE. Чтобы избежать лишних сетевых походов, можно применять локальный кеш с периодической синхронизацией (Local Batching), принимая небольшую погрешность в точности лимитов.

Места размещения лимитера

• Клиентская сторона: для уменьшения лишних запросов.
• Edge/CDN: для блокировки вредоносного трафика на подступах.
• App Level: для сложной бизнес-логики лимитов (по ID пользователя).

10. Проектирование рекламной системы (AdTech)

AdTech в 2026 году — это сверхнизкие задержки (RTB — Real Time Bidding должен отрабатывать за 10-50 мс) и обработка колоссальных потоков событий кликов и показов.

Real-Time Bidding (RTB)

Когда пользователь заходит на сайт, отправляется запрос на аукцион. Наша система (DSP) должна за миллисекунды решить, покупать ли показ. Мы используем предварительно рассчитанные профили пользователей в In-memory БД (Aerospike) и предиктивные модели, развернутые максимально близко к источнику трафика.

Click Fraud Detection

Защита от скликивания требует анализа паттернов поведения в реальном времени. Мы используем Flink или Spark Streaming для обработки потока кликов и выявления аномалий (например, 1000 кликов с одного IP за секунду). Данные затем сохраняются в ClickHouse для последующего аудита.

Компоненты рекламного движка

• Ad Server: отдает креативы.
• Campaign Manager: интерфейс для рекламодателей.
• Billing Service: списание денег за показы/клики (требует высокой точности).
• Analytics Engine: агрегация данных по кампаниям.

11. Проектирование платежного шлюза (Stripe/PayPal)

В 2026 году платежные системы должны гарантировать атомарность операций и соответствие стандартам безопасности (PCI DSS) в распределенной среде. Главное слово здесь — Идемпотентность.

Гарантии доставки и обработки

Каждый платежный запрос должен иметь уникальный `idempotency_key`. Если клиент отправил запрос дважды из-за сбоя сети, система должна вернуть результат первой операции, а не проводить платеж повторно. Мы используем таблицу идемпотентности в БД, где храним статус обработки каждого ключа.

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

Поскольку платеж затрагивает несколько сервисов (баланс пользователя, счет мерчанта, антифрод), мы используем паттерн Saga (Orchestration-based). Если один из шагов не удался, выполняются компенсирующие транзакции для возврата системы в исходное состояние.

Безопасность и комплаенс

• Шифрование данных карт (Tokenization).
• Аудит-логи: неизменяемая запись всех действий.
• Интеграция с внешними банковскими API через надежные очереди.

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

Задача фокусируется на синхронизации файлов, дедупликации и эффективном использовании пропускной способности сети.

Синхронизация по чанкам

Файлы разбиваются на блоки (например, по 4 МБ). Если пользователь меняет только одну строку в документе, мы передаем только измененный чанк. Для определения изменений используется хеширование. Метаданные (структура папок, версии файлов) хранятся в реляционной БД, а сами чанки — в S3.

Конфликты версий

В 2026 году для совместной работы в реальном времени используются CRDT (Conflict-free Replicated Data Types) или Operational Transformation (OT). Для обычных файлов применяется стратегия «последний записавший выигрывает» с сохранением истории версий, чтобы пользователь мог откатиться назад.

Оптимизация хранилища

Заключение и план подготовки

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

Чек-лист для подготовки

• Освежите знания CAP-теоремы и её современной интерпретации (PACELC).
• Изучите специфику работы современных БД (LSM-trees vs B-trees).
• Потренируйтесь делать быстрые оценки (сколько памяти нужно для 1 млрд пользователей).
• Разберитесь в протоколах: HTTP/3, QUIC, gRPC, Avro.
• Всегда начинайте с уточнения требований (Functional & Non-functional).

Для глубокого погружения рекомендую изучить документацию крупных Open Source проектов и блоги компаний (Netflix Tech Blog, Uber Engineering), где они описывают реальные инциденты и архитектурные изменения. Удачи на собеседованиях!