System Design
Архитектурное «мясо»: то, чем оперируешь, когда рисуешь систему на доске, плюс как проходить саму сисдиз-секцию (тайминг, C4, фрейм ответа) — см. в конце.
Нефункциональные требования (NFR)
- latency / throughput
- SLA / SLO / availability
- scalability (вертикальная vs горизонтальная)
- consistency vs availability (CAP)
- cost awareness
- security & compliance
API & контракты
- REST vs GraphQL vs gRPC
- версионирование API
- идемпотентность
- пагинация (offset vs cursor)
- rate limiting / throttling
- backward compatibility
Кэширование
- где кэшировать: CDN / reverse proxy / app / DB
- write-through / write-back / cache-aside
- инвалидация кэша
- Redis vs Memcached
Асинхронщина и фоновые задачи
- когда синхрон, когда async
- очереди vs event streaming
- exactly-once / at-least-once
- дедупликация задач
- идемпотентные воркеры
Надёжность и отказоустойчивость
- retries с backoff + jitter
- circuit breaker
- timeouts
- graceful degradation
- bulkheads
Observability
- structured logs
- метрики (RED / USE)
- трассировка
- алерты: когда и на что
Миграции и эволюция системы
- zero-downtime migrations
- feature flags
- blue/green vs canary
- как менять схему БД без даунтайма
Архитектурные подходы (DDD + event-driven)
- Когда DDD — оверхед?
- Как bounded context ложится на микросервисы?
- Что делать, если бизнес-логика простая?
- Repository на примере abstraction над storage: почему не дергать ORM напрямую?
- Entity vs Value Object
- Event vs Command: CreateOrder (command) vs OrderCreated (event)
- PubSub: producer не знает consumer + слабая связность системы
- Eventual Consistency: данные сходятся “не сразу” + между сервисами нет транзакций. Пример: пользователь создал заказ, но не видит его сразу — почему?
- Outbox Pattern
Ссылочки, пока работают
Базы данных
- OLTP vs OLAP
- read-heavy vs write-heavy
- когда индексы вредят
- composite indexes
- hot keys
- реплика лаг и его последствия
- шардинг: по чему и какие проблемы
Очереди
Главное — модель мышления, а не список отличий.
- queue vs log
- ordering
- retention
- replay
- consumer groups
- exactly-once (почему почти никогда нет)
- «У тебя события оплаты и уведомления. Какую очередь выберешь и почему?»
Kubernetes
- зачем вообще k8s
- pod vs deployment vs statefulset
- config & secrets
- liveness / readiness
- scaling стратегии
- как сервисы находят друг друга
- Почему нельзя просто увеличить replicas и всё станет хорошо?
Облака
- managed vs self-hosted
- vendor lock-in
- стоимость
- сети (VPC, private/public)
- IAM и безопасность
- Что ты возьмёшь managed, а что оставишь самописным — и почему?
Процесс сисдиз-интервью
Общие рекомендации
- нужно брать инициативу на себя и вести процесс проектирования решения (буквально показать что ты “ведущий” разработчик)
- проговаривать и фиксировать все нюансы стикерами на схеме
- c4 model знать как устроена и применять на интервью. Нам понадобятся первые два уровня + список требований
- подготовить миро доску заранее с частыми компонентами и научиться с ней работать, чтобы не тупить на интервью
- следить за таймингом самому (10 минут сбор требований, 15 минут С1, 25 минут С2, 10 минут запаса на обсудить что забыли и не учли)
- общая архитектура приложения важнее детальных апишек/контроллеров
- строить речь коротко и чётко по делу, смысла растягивать интервью тут мало - наша задача за час нарисовать на “салфетке” цельную систему и доказать что это будет решать наши задачи и масштабироваться при росте нагрузки
- весь фокус на критическом пути юзера. Всё что стороннее рисуем сбоку на схеме и проговариваем, что это не рассматриваем сегодня
- дискретные ответы не наш путь: не “берём PG как бд”, а “исходя из типа нагрузки и объёма данных берём sql совместимую БД и предусматриваем несколько реплик на чтение”
- строить сверху вглубь, никаких конкретных технологий на первом уровне диаграмм
- не забыть оценку нагрузки и подсвечиваем бутылочные горлышки стикерами на схеме
- рисуем как мы эти горлышки будем расшивать масштабируясь
- нужно выбрать стек правильно (от наших требований к пропускной способности)
- нужно выбрать базу правильно (от наших требований и интенсивности записи-чтения)
- нужно не забыть про кеш (и как мы его инвалидируем!)
- нужно не забыть про масштабирование и разделение всего и вся в этом контексте
Бонусные секции, если осталось время
- оценить стоимость поддержки (в том числе найма)
- оценить стоимость железа на всё про всё и подсветить как будет расти при масштабировании
Универсальный фрейм для любого вопроса
- Уточнение контекста
- нагрузка
- тип данных
- SLA
- команда / сроки
- Простое базовое решение
- Проблемы базового решения
- Улучшения по мере роста
- Трейдофы