System design интервью пугают большинство разработчиков, потому что задача неограниченна. «Спроектируй Twitter». «Спроектируй URL-shortener». «Спроектируй распределённый кеш». С чего вообще начать?
После 100+ технических интервью и менторинга инженеров для FAANG и MAANG я свёл процесс к повторяемому фреймворку. Вот он.
6-шаговый фреймворк
Шаг 1: Уточните требования (5 минут)
Никогда не начинайте проектировать без этих вопросов:
- Масштаб: Сколько пользователей? Read-heavy или write-heavy? Ожидаемые QPS (запросы в секунду)?
- Consistency vs availability: Нормально ли отдавать слегка устаревшие данные? Можем ли потерять запись?
- География: Один регион или глобально?
- SLA: Какая допустимая latency? Требование к uptime?
Большинство кандидатов это пропускают и сразу рисуют квадратики. Интервьюеры замечают. Senior сначала задаёт вопросы.
Шаг 2: Определите API-контракт
До любой инфраструктуры — что система отдаёт наружу:
POST /urls
Body: { "long_url": "https://example.com/very-long-path" }
Response: { "short_code": "abc123", "short_url": "https://short.ly/abc123" }
GET /{short_code}
Response: 301 Redirect to long_urlЭто заставляет думать о пользовательском контракте до деталей реализации.
Шаг 3: Оцените масштаб (back-of-envelope)
Считайте вслух:
- «100M URL в день = ~1 200 записей/сек»
- «Соотношение read/write 10:1 = 12 000 чтений/сек»
- «Средний URL ~500 байт, 100M/день × 365 дней × 500 байт = ~18ТБ/год»
Точные числа не нужны. Нужно показать, что вы мыслите порядками величин.
Шаг 4: Спроектируйте data model
SQL vs NoSQL — почти всегда первое реальное решение:
| Фактор | В пользу SQL | В пользу NoSQL |
|---|---|---|
| Нужна strong consistency | ✅ | ❌ |
| Сложные join’ы / отчёты | ✅ | ❌ |
| Горизонтальный масштаб 100M+ строк | Сложнее | ✅ |
| Схема стабильна | ✅ | Любое |
| Access pattern — key-value | Любое | ✅ |
Для URL-shortener простой key-value (Redis или DynamoDB) для lookup — правильный выбор. Метаданные (время создания, click-аналитика) — в PostgreSQL.
Шаг 5: Компоненты системы
Рисуйте квадратики и объясняйте каждый:
Client → CDN/Load Balancer → API Servers (stateless)
→ Redis (short_code → long_url кеш)
→ PostgreSQL (метаданные, аналитика)Затем разбирайте сложное:
- Генерация short_code: Base62 от auto-increment ID, либо hash + обработка коллизий
- Cache invalidation: TTL на записях Redis, write-through на создании
- Rate limiting: per-IP, алгоритм token bucket
Шаг 6: Bottlenecks и trade-offs
Здесь senior отделяется от mid’а. Проактивно обсуждайте:
- Single points of failure: «БД — SPOF; добавим read-реплики и primary failover»
- Горячие партиции: «Если short URL виральный, один Redis-нод бьётся; consistent hashing распределяет нагрузку»
- Стоимость vs производительность: «CDN-кеширование экономит 90% обращений к origin, но добавляет риск stale-редиректов для удалённых URL»
Что интервьюеры реально оценивают
- Коммуникацию: Можете объяснить мысли вслух?
- Системную декомпозицию: Разбиваете задачу на части?
- Awareness trade-off’ов: Понимаете, что идеального ответа нет?
- Production-mindset: Думаете о failure modes, не только о happy path?
Не проверяют, помните ли вы наизусть архитектурные диаграммы. Проверяют, как вы думаете.
Единственное практическое упражнение, которое работает
Возьмите любое приложение, которым пользуетесь ежедневно (Slack, Netflix, мобильный банк). За 20 минут на бумаге набросайте:
- Какие основные сущности?
- Какое соотношение read/write?
- Где bottlenecks?
- Как масштабировать в 10× к текущей нагрузке?
Сделайте это 20 раз. И белая доска перестанет пугать.
Мышление system design мы разбираем в курсе Backend Architecture Foundations — где учат думать как senior до того, как им станешь.
