System Design и распределённые системы
Как проектировать системы под нагрузку: подход к system design интервью, масштабирование, согласованность и консенсус, распределённые блокировки, проектирование API, multi-tenancy, надёжность, разборы кейсов и роль Senior-инженера.
Вопросы уровня Senior: здесь важны не конкретные API, а умение рассуждать о компромиссах — задержка против согласованности, простота против масштабируемости, стоимость против надёжности. Хороший ответ всегда начинается с уточнения требований и заканчивается явным перечислением trade-offs.
- 1 Как проходить system design интервью: требования, оценки, архитектура, компромиссы? System design интервью проверяет не «правильный ответ», а ход мысли: умение уточнить задачу, оценить масштаб, предложить простую рабочую архитектуру, найти узкие места и… Senior7 мин
- 2 Масштабирование: вертикальное и горизонтальное, stateless, балансировка нагрузки L4/L7? Вертикальное масштабирование (scale up) — больше CPU/RAM на одной машине: просто, но есть потолок, растёт цена, остаётся единая точка отказа. Горизонтальное (scale out) … Senior7 мин
- 3 Модели согласованности и консенсус: strong, eventual, кворумы, Raft? Модель согласованности — гарантия, что увидит чтение после записи в распределённой системе с репликами. От строгой к слабой: линеаризуемость (strong) → последовательная … Senior7 мин
- 4 Распределённые блокировки и выбор лидера: Redis, PostgreSQL advisory locks, fencing tokens? Распределённая блокировка гарантирует, что операцию выполняет один экземпляр из многих: фоновая задача по расписанию, обработка одного заказа, миграция, вызов API с жёст… Senior6 мин
- 5 Проектирование API: пагинация, идемпотентность, версионирование, обратная совместимость? Публичный API — контракт, который трудно менять: клиенты (мобильные приложения, партнёры) обновляются месяцами. Проектируйте его как продукт: последовательные имена, пре… Senior7 мин
- 6 Multi-tenancy: как изолировать данные клиентов в SaaS на .NET? Multi-tenancy — одна система обслуживает много клиентов-организаций (тенантов), изолируя их данные, настройки и нагрузку. Главный риск — утечка данных одного тенанта дру… Senior7 мин
- 7 Высокая нагрузка: как масштабировать чтение и запись (кэши, реплики, CQRS, очереди, шардирование)? Сначала измерьте: где узкое место (CPU приложения, БД, сеть, блокировки), какое отношение чтения к записи, какие запросы самые тяжёлые. Оптимизация запросов и индексов ч… Senior7 мин
- 8 Развёртывание без простоя: rolling update, graceful shutdown, миграции БД по схеме expand/contract? Развёртывание без простоя требует, чтобы старая и новая версии работали одновременно: при rolling update часть подов уже новая, часть ещё старая — и обе ходят в одну БД … Senior7 мин
- 9 Надёжность: SLO, error budget, отказоустойчивость, управление инцидентами и постмортемы? SLI — измеряемый показатель качества (доля успешных запросов, p99 задержки), SLO — целевое значение (99,9% за 30 дней), SLA — договорное обязательство перед клиентом со … Senior7 мин
- 10 Разбор кейса: спроектировать сервис сокращения ссылок Классическая задача, на которой проверяют весь цикл: требования → оценки → API → хранение → генерация кодов → кэширование → аналитика → масштабирование и отказы. Ключевы… Senior6 мин
- 11 Разбор кейса: система уведомлений (email, SMS, push) с гарантиями доставки Задача проверяет асинхронную архитектуру: приём запросов → очередь → обработчики по каналам → внешние провайдеры с ретраями, лимитами и отслеживанием статусов. Ключевые … Senior6 мин
- 12 Чем Senior отличается от Middle: зона ответственности, влияние, техническое лидерство? Разница не в количестве известных технологий, а в масштабе ответственности и влияния: Middle самостоятельно решает поставленные задачи; Senior определяет, какие задачи р… Senior6 мин