Чему вы научитесь
- Проходить секцию системного дизайна способом думать, а не заученным шаблоном: разворачивать задачу, считать, рисовать, называть компромиссы вслух и выдерживать встречные вопросы
- Проводить границу внутри системы: решать, что остаётся модулем, а что становится сервисом, и обосновывать это владением данными и темпом изменений, а не модой на распил
- Называть режим отказа по симптому — дубль, потеря, перестановка, рассогласование, каскад — и подбирать защиту, зная, что она гарантирует и чем за это платит
- Разворачивать расплывчатую задачу в требования с числами и считать систему на салфетке: RPS, объём хранения, число обработчиков — чтобы проверить счётом, нужна ли ей распределённая архитектура вообще
- Проектировать поток событий: выбирать между очередью и логом, задавать ключ партиционирования, делать потребителя переживающим повтор, планировать DLQ и повторную обработку
- Проводить длинный бизнес-процесс через несколько сервисов, не теряя событий: outbox, CDC, сага с компенсациями — и объяснять, почему запись в базу и в брокер сразу это баг, а не оптимизация
- Проектировать межсервисный контракт и проводить его через изменение схемы, не сломав ни одного потребителя: идемпотентность, единый формат ошибок, совместимость версий
- Говорить, что именно система гарантирует при отказе узла и разрыве сети: кворум, выбор лидера, порядок событий, CAP и PACELC как формулировка выбора, а не как слоган
- Разводить путь чтения и путь записи и называть окно рассогласования каждой копии данных: проекции, CQRS, кэш и его инвалидация между сервисами
- Проектировать рост: stateless-слой, балансировку, шардирование с честным ключом, репликацию чтения и осознанную жизнь с лагом
- Делать систему наблюдаемой по устройству — сквозной контекст запроса через HTTP и брокер, метрики по RED и USE, SLO с бюджетом ошибок — и проверять архитектурную гипотезу до прода контрактом, внесённым отказом и нагрузочным профилем
- Проводить систему через изменение без простоя и записывать решения так, чтобы через полгода их можно было понять и оспорить по существу
О курсе
Для кого этот курс
Начальные требования
Что нужно знать
- Пишешь бэкенд-сервис на каком-либо языке: маршруты, обработчики, слои, зависимости.
- Понимаешь HTTP и REST на рабочем уровне: методы, коды ответов, тело запроса, заголовки.
- Работаешь с реляционной базой через ORM или SQL: таблицы, связи, транзакция как понятие.
- Запускаешь приложение в Docker и умеешь прочитать файл docker compose.
- Терминал: запустить команду, посмотреть логи, зайти в контейнер.
Что нужно на машине
- Ноутбук с Docker и Docker Compose: macOS, Linux или Windows с WSL2.
- Около 4 гигабайт свободной оперативной памяти на профиль стенда — тяжелее ни один модуль не требует.
- Терминал и git, чтобы забрать репозиторий стенда. Всё остальное приезжает образами по ходу курса.
Стенд при этом не пропуск, а усилитель: вывод каждой сцены приведён в самом шаге, поэтому курс читается и решается даже с телефона в метро, а запуск даёт то, чего чтением не получишь — руки на разорванной сети.
В этой же линейке есть входные курсы — по бэкенду на Python и по базам данных, — если из первого списка чего-то не хватает. Формально ни один из них не требуется: этот курс автономен и языку не учит.
Преподаватели курса
94
Как проходит обучение
Короткие шаги, каждый устроен одинаково: разбор механики, артефакт, вопрос, на который без разбора не ответишь.
Квизы-диагностики — основная проверяемая форма. Это не проверка памяти на термины. На входе всегда артефакт: timeline двух сервисов, лог повторов, трейс, порвавшийся о брокер, фрагмент контракта, набор метрик, конфигурация брокера. А вопрос звучит как «что окажется в базе», «почему сервис не встаёт после перезапуска», «где потерялся контекст запроса», «что вернуть клиенту сейчас». Неверный вариант — это типичная ошибка проектирования, а не глупость, и объяснение механики приходит вместе с ответом. Первая ошибка здесь обычно случается быстрее, чем ожидаешь, — это и есть самая честная проверка, не пересказ ли это докладов, которые ты уже смотрел.
Стенд на Docker Compose. Растёт вместе с курсом: начинается с монолита службы доставки и базы, к финалу это кластер из трёх брокеров, несколько сервисов, трейсинг и разрываемая сеть. Сцена запускается одной командой, в шаге сказано, что именно смотреть — какая команда, какой вывод, какое поле, — а результат наблюдения проверяется квизом. Сервисы внутри приходят готовыми образами: язык их реализации студента не касается.
Проектные шаги и дизайн-док. В конце модуля — не «повтори за автором», а спроектируй своё: проведи границу, выбери обмен, спроектируй поток событий, напиши ADR, защити решение. Шаг даёт шаблон раздела и критерии, по которым решение считается защищённым, а сразу за ним идёт квиз по этим критериям — чтобы проектный шаг оставил след, а не ощущение.
Чего здесь нет: задач с автопроверкой кода. Это осознанное решение, а не недоделка. Автопроверка на Stepik означала бы конкретный язык — то есть половину аудитории за бортом, — а курс языконезависим по устройству. Проверяемость держится на другом: квиз ловит ошибку рассуждения, стенд показывает поведение системы, дизайн-док остаётся у тебя как доказательство. Если тебе нужно «прошёл тесты — значит умею», честнее знать это до покупки.
Гильдия вайба — сообщество курса. Проходить в одиночку не обязательно, и здесь это особенно заметно: архитектурное решение нельзя проверить компилятором, его проверяют встречным вопросом. В Гильдию приносят не сломанный код, а схему — «нам говорят пилить, вот мой дизайн, где я не прав», — и получают ревью, которого на работе часто просто нет. Там же помощь по шагам, разбор чужих архитектур, поиск тиммейтов и общение с теми, кто идёт тем же путём. Правило простое: чем активнее участвуешь, тем больше берёшь от курса.
Что вы получите
- Собственный дизайн-док службы доставки: требования и числа, карта границ с хозяевами данных, контракты, поток событий, каталог отказов, SLO, ADR. Документ, который можно принести на ревью и открыть на секции системного дизайна
- Каталог отказов «симптом — механика — защита — цена» — рабочая шпаргалка, по которой поломка называется за секунды, а не подбирается наугад
- Набор собственных ADR и навык писать их так, чтобы через полгода решение можно было понять и оспорить по существу — с названной альтернативой и названной ценой
- Отработанный формат системного дизайна вслух: порядок разбора, распределение времени, ответ на встречный вопрос — на двух полных разборах (распродажа билетов, маркетплейс с внешними продавцами) и на защите своего дизайна
- Стенд, который остаётся у тебя: монолит, брокеры, кластер из трёх узлов, разрываемая сеть. Сцены можно перезапускать, когда тема всплывёт на работе
- Способность назвать вслух, что покупается, чем оплачивается и какая была альтернатива, — и выдержать три встречных вопроса, а не сдаться на первом
- Доступ в Гильдию вайба, который не кончается вместе с курсом: место, куда приносят архитектурное решение на ревью