System Design
Метод проектирования систем: от требований до письменного анализа компромиссов.
Эта программа планируется и ещё не включена в расписание. Дата, цена и группа не объявлены. Если вы оставите интерес, мы свяжемся, когда программа будет запланирована, или чтобы обсудить индивидуальный формат.
Цель
Программа рассматривает проектирование систем как повторяемый метод: определить требования и атрибуты качества, оценить масштаб, построить API и модель данных и обосновать выбор через компромиссы. Метод применяется к 6–8 классическим case study, и каждое заканчивается письменным анализом компромиссов.
Для кого
- Кандидаты на уровень senior, которые хотят учиться мыслить backend-системами целиком
- Те, кто движется к роли tech lead или архитектора
- Инженеры, которые хотят структурно аргументировать позицию в обсуждениях дизайна
- Те, кто хочет собрать знания о микросервисах, базах данных и обмене сообщениями в единую рамку
Для кого не подходит
- Те, у кого нет опыта backend: сначала рекомендуется Java Backend Career Track
- Те, кто ищет заученные шаблоны ответов для собеседований: программа делает упор на рассуждение, а не заучивание
- Те, кто хочет изучить настройку конкретной технологии
Требования
- Опыт написания реальных backend-сервисов
- Основы SQL, индексов и транзакций
- HTTP и дизайн REST API
- Понимание, что такое cache и message queue
Что вы сможете делать
Что вы сможете делать
- Превратить неопределённую задачу в функциональные и качественные требования
- Проводить простые оценки трафика, хранилища и bandwidth
- Проектировать API и модель данных под шаблоны доступа
- Оценивать стратегию кэширования (aside, write-through) и риск инвалидации
- Обосновывать, когда нужны очередь и асинхронная обработка
- Сравнивать варианты хранилищ (relational, key-value, search, object) под нагрузку
- Анализировать варианты масштабирования чтения и записи (replica, sharding, partitioning)
- Перечислять режимы отказа и предлагать ответ для каждого
Ни одна образовательная программа не может гарантировать трудоустройство или повышение.
Учебный план
Учебный план
- 01
Требования и атрибуты качества
Перед проектированием уточняем, что мы решаем и что не решаем.
- Функциональные и нефункциональные требования
- Атрибуты доступности, задержки, надёжности и согласованности
- Явная запись ограничений и допущений
- Понятия SLI и SLO
- Ограничение scope
Практическая лабораторная: Для неопределённой задачи написать список требований и допущений и определить не-цели.
- 02
Оценка нагрузки
Нужна не точная цифра, а порядок величины, влияющий на решение.
- Запросы в секунду и пиковый коэффициент
- Расчёт хранилища и bandwidth
- Соотношение чтения и записи
- Как оценка меняет решение
- Открытое указание допущений
Практическая лабораторная: Подготовить оценку трафика и хранилища для выбранной системы и записать, на какое решение влияет результат.
- 03
Дизайн API и данных
Начинаем с шаблонов доступа и строим под них API и модель данных.
- Дизайн ресурсов и операций
- Пагинация, идемпотентность и rate limit
- Нормализация и денормализация
- Соответствие индексов шаблонам доступа
- Эволюция схемы
Практическая лабораторная: Составить контракт API и схему таблиц для заданной системы и объяснить, как выполняются ключевые запросы.
- 04
Кэширование и очереди
Оцениваем пользу и риск двух главных инструментов снижения задержки и сглаживания нагрузки.
- Cache-aside, write-through, write-behind
- Инвалидация и устаревшие данные
- Cache stampede и защита
- Развязка нагрузки очередями и backpressure
- Dead letter и повторные попытки
Практическая лабораторная: Добавить кэш в сервис с преобладанием чтения и смоделировать сценарии устаревших данных и stampede.
- 05
Выбор хранилища и масштабирование
Выбираем хранилище под нагрузку и сравниваем варианты масштабирования чтения и записи.
- Relational, key-value, document, search и object storage
- Read replica и задержка репликации
- Ключ sharding и сложность re-sharding
- Проблема hot key
- Практический смысл CAP и PACELC
Практическая лабораторная: Написать краткий документ решения, сравнивающий два варианта хранилища для одной и той же нагрузки.
- 06
Согласованность и режимы отказа
Заранее продумываем, где и как система сломается.
- Strong, eventual и causal consistency
- Поиск single point of failure
- Timeout, retry и идемпотентность
- Частичный отказ и стратегия деградации
- Основы disaster recovery: RPO и RTO
Практическая лабораторная: Подготовить таблицу режимов отказа для спроектированной системы с ответом и оценкой ущерба для каждого.
- 07
Case study I: URL shortener, rate limiter, уведомления
Применяем метод к трём классическим задачам с относительно узким scope.
- URL shortener: генерация ID, нагрузка на редирект, аналитика
- Rate limiter: token bucket, sliding window, распределённые счётчики
- Система уведомлений: каналы, приоритеты, повторные попытки
- Оценка и анализ компромиссов для каждой
Практическая лабораторная: Выбрать две из трёх задач и подготовить полный письменный документ дизайна с анализом компромиссов.
- 08
Case study II: payments ledger, feed, поиск
Разбираем три задачи, более сложные по согласованности, масштабу и поиску.
- Payments ledger: двойная запись, идемпотентность, аудит
- Feed: fan-out on write и on read, горячие пользователи
- Поиск: инвертированный индекс, задержка индексации, релевантность
- Анализ согласованности и отказов для каждой
Практическая лабораторная: Выбрать одну из трёх задач, написать документ дизайна и переработать его после peer review.
Практические задания
- Документ требований и допущений
- Оценка трафика и хранилища
- Дизайн API и модели данных
- Документ решения по выбору хранилища
- Документ дизайна case study и peer review
Результаты для портфолио
- Письменные документы дизайна по 6–8 case study
- Анализ компромиссов и альтернатив в каждом дизайне
- Таблица режимов отказа
- Краткий ADR для выбранного дизайна
Как оценивается обучение
- Защита дизайна (перед ментором и коллегами)
- Письменный разбор case study
- Peer review дизайна
- Обратная связь ментора о качестве аргументации компромиссов
Инструменты и технологии
- PostgreSQL
- Redis
- Kafka или RabbitMQ
- Elasticsearch или OpenSearch (на уровне концепции)
- Модель C4
- Инструменты диаграмм
- Шаблоны ADR
- k6 или JMeter (простые нагрузочные тесты)
Последовательность уровней
- До
- До этого: Microservices и Distributed Systems, Kafka и Event-Driven Architecture или равноценный опыт.
- После
- После: программы в направлении tech lead или solution architect.
- Длительность и формат
- Длительность и формат ещё не определены; программа планируется и не включена в расписание.
Частые вопросы
Частые вопросы
Доступна ли программа сейчас?
Нет. Программа планируется и пока не стоит в расписании. Даты и цены не объявлены. Вы можете оставить интерес или запросить консультацию.
Это подготовка к собеседованию?
Главная цель — реальное проектное мышление. Метод может помочь и на собеседованиях, но заученных шаблонов и обещаний результата нет.
Мы будем писать код или только рисовать диаграммы?
Основной результат — письменные документы дизайна. В некоторых лабораториях проводятся небольшие эксперименты с кэшем, нагрузкой и планами запросов.
Есть ли сертификат или обещание работы?
Нет. Ни сертификат, ни результат не обещаются. Оценка проходит в форме защит дизайна и обратной связи ментора и носит рекомендательный характер.
Статьи по теме программы
- System DesignCaching strategies - cache-aside, write-through, TTLs and stampedes
- Облачная архитектураCloud architecture basics for backend engineers
- Распределённые системыFailure handling in distributed systems
- Распределённые системыIdempotency patterns for safe retries
- SQL и производительностьSQL indexes explained with PostgreSQL EXPLAIN
- System DesignA repeatable method for system design interviews and design reviews