System design - секция процесса собеседований, которая отделяет специалистов уровня middle от специалистов уровня senior и пугает больше всего: нет «правильного» ответа, доска пустая, время идёт. Но за кажущимся хаосом стоит чёткий каркас. Освоив его, вы перестаёте паниковать и начинаете вести интервью сами. Этот лонгрид разбирает каркас по шагам и прогоняет через него три классические задачи.
Коротко:
- System design проверяет ход мысли и trade-offs, а не заученную схему.
- Каркас один: требования → масштаб → схема → углубление → компромиссы.
- Главные строительные блоки: балансировка, кэш, база, шардирование, очереди.
- Худшая ошибка - сразу рисовать, не уточнив, что вообще строим.
Что на самом деле проверяют
Интервьюер не ждёт «единственно верную» архитектуру - её не существует. Он смотрит, умеете ли вы:
- разложить размытую задачу на требования;
- оценить масштаб и выбрать решения под него;
- видеть узкие места и осознанно идти на компромиссы;
- объяснять, почему так, а не иначе.
Поэтому system design - это разговор, а не рисунок. Кандидат, который молча чертит «идеальную» схему, проигрывает тому, кто рассуждает вслух и обосновывает выбор.
Каркас из пяти шагов
Шаг 1. Уточнить требования. Не бросайтесь к доске. Спросите, что система должна делать (функциональные требования) и каковы ограничения (нефункциональные требования - нагрузка, латентность, доступность, согласованность). Сузьте scope: «Сфокусируемся на основном сценарии?».
Шаг 2. Прикинуть масштаб. Грубая оценка: сколько пользователей, RPS на чтение и запись, объём данных, соотношение read/write. Это определяет, нужны ли кэш, шардирование, реплики. Точность не важна, важен порядок величин.
Шаг 3. Высокоуровневая схема. Нарисуйте крупными блоками: клиент → балансировщик → сервисы (API) → база данных. Пока без деталей. Проговорите поток данных от запроса до ответа.
Шаг 4. Углубление. Теперь добавляйте под нагрузку: кэш (Redis) для частых чтений, шардирование/репликация базы, очереди (Kafka) для асинхронных задач, CDN для статики, индексы. На каждом блоке проговаривайте, зачем он здесь.
Шаг 5. Trade-offs и узкие места. Проговорите компромиссы: согласованность против доступности, latency против стоимости, что станет бутылочным горлышком при росте и как это лечить. Это и есть senior-уровень разговора.
Строительные блоки, которые надо знать
- Балансировщик нагрузки - распределяет трафик между серверами.
- Кэш (Redis/Memcached) - ускоряет частые чтения, снимает нагрузку с базы.
- Базы: SQL vs NoSQL - реляционная для связей и транзакций, NoSQL для масштаба и гибкой схемы.
- Шардирование и репликация - горизонтальное масштабирование и отказоустойчивость.
- Очереди (Kafka, RabbitMQ) - асинхронная обработка, развязка сервисов.
- CDN - раздача статики ближе к пользователю.
- Теорема CAP - в распределённой системе нельзя одновременно максимизировать согласованность и доступность при разрыве сети; выбираете приоритет под задачу.
Пример 1. Сокращатель ссылок (URL shortener)
Классическая разминочная задача.
- Требования: создать короткую ссылку по длинной, редиректить по короткой. Read >> write.
- Масштаб: допустим, 100M ссылок, чтений намного больше, чем записей.
- Схема: API для создания/редиректа, база (ключ - короткий код, значение - длинный URL), кэш для горячих ссылок.
- Углубление: генерация короткого кода (хеш или счётчик в base62), кэш Redis для популярных ссылок (read-heavy), реплики на чтение.
- Trade-offs: коллизии хешей против длины кода; согласованность против скорости.