Системный дизайн
Очереди сообщений, RPC, gRPC и проектирование систем.
9 вопросов
MiddleТеорияОчень частоКак делать оценку нагрузки для системы?
Как делать оценку нагрузки для системы?
Прикинуть размеры данных (символ ~1 байт, метаданные ~КБ, картинка ~МБ) и трафик, затем вывести RPS на чтение и запись (дневное число ÷ 86 400), объём хранения за день или месяц и полосу — помня, что пиковый трафик бывает примерно в 10 раз выше среднего.
Типичные ошибки
- ✗Брать дневное число запросов за
RPSвместо деления на 86 400 секунд - ✗Игнорировать пиковый трафик и считать только средний устойчивый уровень
- ✗Забывать оценить рост хранилища и полосу наряду с темпом запросов
Уточняющие вопросы
- →Как оценить хранилище на пять лет роста с запасом прочности?
- →Почему при выделении серверов считать по пиковому
RPS, а не по среднему?
MiddleТеорияОчень частоВертикальное и горизонтальное масштабирование: чем отличаются и почему горизонтальное — главный рычаг?
Вертикальное и горизонтальное масштабирование: чем отличаются и почему горизонтальное — главный рычаг?
Вертикальное масштабирование берёт машину мощнее и быстро упирается в потолок; горизонтальное добавляет узлы за load balancer и масштабируется почти линейно — поэтому это главный рычаг роста. Оно требует сервисов без состояния, чтобы любой узел обслуживал любой запрос.
Типичные ошибки
- ✗Ждать, что
load balancerмасштабирует сервисы с состоянием, не убирая локальную сессию - ✗Считать, что у одной мощной машины нет потолка и она масштабируется как добавление узлов
- ✗Путать рост пропускной способности от узлов со снижением задержки одного запроса
Уточняющие вопросы
- →Почему сервис должен быть без состояния, чтобы масштабироваться за
load balancer? - →Где хранить состояние сессии, убрав его из узлов приложения?
JuniorТеорияЧастоЧто такое очередь сообщений (message queue) и зачем она нужна?
Что такое очередь сообщений (message queue) и зачем она нужна?
Брокер, передающий сообщения между производителями и потребителями и развязывающий их: производитель кладёт сообщение в очередь и идёт дальше, а потребители обрабатывают асинхронно в своём темпе — это даёт буферизацию пиков, повторы и масштабирование.
Типичные ошибки
- ✗Думать, что очередь делает вызовы синхронными, а не развязывает производителя и потребителя
- ✗Считать, что при недоступном потребителе сообщения теряются, а не буферизуются
- ✗Путать очередь сообщений с обычной таблицей в БД без семантики повторов
Уточняющие вопросы
- →Как очередь обрабатывает сообщение, которое потребитель не смог обработать — повторы и dead-letter?
- →Чем очередь точка-точка отличается от модели публикации-подписки (
pub-sub)?
MiddleТеорияЧастоКак мониторить веб-приложение в production?
Как мониторить веб-приложение в production?
По трём столпам: метрики (частота запросов, ошибок, задержка — метод RED — через Prometheus/Grafana), логи (структурированные, централизованные) и трейсы (распределённый поток запроса). Плюс health-чеки, алерты на нарушение SLO и трекинг ошибок вроде Sentry. Следи за golden signals, а не только за CPU.
Типичные ошибки
- ✗Приравнивать мониторинг к простому пингу доступности
- ✗Смотреть только CPU/RAM хоста, игнорируя golden signals приложения
- ✗Быть реактивным (логи после жалоб) вместо алертов на нарушение SLO
Уточняющие вопросы
- →Что такое методы RED и USE и когда применяется каждый?
- →Чем различаются метрики, логи и трейсы и зачем нужны все три?
MiddleТеорияЧастоЧто такое sharding базы и какое решение здесь ключевое?
Что такое sharding базы и какое решение здесь ключевое?
Sharding горизонтально разбивает данные по нескольким базам, чтобы каждая хранила подмножество, распределяя нагрузку и хранение шире одного узла. Ключевой выбор — ключ шардирования: он должен ровно распределять данные и трафик под частые запросы.
Типичные ошибки
- ✗Путать
sharding(разбиение данных) с репликацией (полное копирование) - ✗Брать ключ шардирования, создающий горячие точки или joinы между шардами
- ✗Считать
shardingвертикальным наращиваниемCPUи памяти одного сервера
Уточняющие вопросы
- →Чем различаются
shardingпо диапазону, по хешу и по справочнику? - →Какие проблемы возникают, когда запрос должен join-ить данные между шардами?
JuniorТеорияИногдаКакие шаги структурируют интервью по системному дизайну?
Какие шаги структурируют интервью по системному дизайну?
Уточнить требования, сделать оценку нагрузки, определить API, набросать высокоуровневый дизайн из компонентов и их взаимодействий, затем детализировать с компромиссами и узкими местами и обсудить масштабирование. Не называть конкретные технологии слишком рано.
Типичные ошибки
- ✗Перескакивать к конкретным технологиям до уточнения функциональных требований
- ✗Пропускать оценку нагрузки и не прикидывать трафик и объём хранения
- ✗Проектировать в вакууме, не озвучивая компромиссы и узкие места
Уточняющие вопросы
- →Какие функциональные и нефункциональные требования вы уточните первыми и почему?
- →Как определить вероятное узкое место до того, как начнёте его масштабировать?
JuniorТеорияИногдаЧто такое RPC (удалённый вызов процедур)?
Что такое RPC (удалённый вызов процедур)?
Техника, позволяющая программе вызвать процедуру в другом адресном пространстве — процессе или машине — будто она локальная. Фреймворк берёт на себя клиент-серверный сетевой протокол и сериализацию аргументов и результатов; вызовы обычно синхронные.
Типичные ошибки
- ✗Считать, что
RPCработает только внутри одного процесса, а не по сети - ✗Забывать, что аргументы и результаты надо сериализовать для передачи
- ✗Думать, что любой
RPCасинхронен, тогда как классический ждёт ответа
Уточняющие вопросы
- →Чем
RPCотличается от вызоваRESTповерхHTTP? - →Что такое язык описания интерфейсов (
IDL) и зачем он фреймворкамRPC?
MiddleТеорияИногдаЧто такое gRPC и на чём он построен?
Что такое gRPC и на чём он построен?
Высокопроизводительный фреймворк RPC от Google поверх HTTP/2, использующий Protocol Buffers для компактной двоичной сериализации и типизированных контрактов. Мультиплексирование и потоки с protobuf делают его быстрым для микросервисов.
Типичные ошибки
- ✗Путать
gRPCсREST/JSONвместоHTTP/2плюсProtocol Buffers - ✗Забывать, что
gRPCподдерживает потоки поверх мультиплексированногоHTTP/2 - ✗Не понимать, что
protobufдаёт типизированную схему и генерируемые заглушки
Уточняющие вопросы
- →Какие четыре режима потоков поддерживает
gRPCповерхHTTP/2? - →Почему
Protocol Buffersкомпактнее и быстрее разбирается, чемJSON?
SeniorТеорияРедкоКак масштабироваться в сторону миллиарда пользователей?
Как масштабироваться в сторону миллиарда пользователей?
Наслаивать приёмы: сервисы без состояния за load balancer, кеширование и CDN, read replica, очередь сообщений и лимиты, NoSQL там, где реляционное масштабирование упирается, sharding базы по хорошему ключу и, наконец, распределение по региональным дата-центрам.
Типичные ошибки
- ✗Считать, что один вертикально масштабированный сервер обслужит миллиард
- ✗Шардировать базу раньше, чем добавлены кеши и
read replica - ✗Думать, что несколько региональных дата-центров снижают доступность
Уточняющие вопросы
- →Когда разумно вводить
NoSQLвместо масштабирования реляционной базы? - →Какие проблемы согласованности возникают, когда данные охватывают несколько регионов?
