Чему вы научитесь
- Проходить секцию системного дизайна способом думать, а не заученным шаблоном: разворачивать задачу, считать, рисовать, называть компромиссы вслух и выдерживать встречные вопросы
- Проводить границу внутри системы: решать, что остаётся модулем, а что становится сервисом, и обосновывать это владением данными и темпом изменений, а не модой на распил
- Называть режим отказа по симптому — дубль, потеря, перестановка, рассогласование, каскад — и подбирать защиту, зная, что она гарантирует и чем за это платит
- Разворачивать расплывчатую задачу в требования с числами и считать систему на салфетке: RPS, объём хранения, число обработчиков — чтобы проверить счётом, нужна ли ей распределённая архитектура вообще
- Проектировать поток событий: выбирать между очередью и логом, задавать ключ партиционирования, делать потребителя переживающим повтор, планировать DLQ и повторную обработку
- Проводить длинный бизнес-процесс через несколько сервисов, не теряя событий: outbox, CDC, сага с компенсациями — и объяснять, почему запись в базу и в брокер сразу это баг, а не оптимизация
- Проектировать межсервисный контракт и проводить его через изменение схемы, не сломав ни одного потребителя: идемпотентность, единый формат ошибок, совместимость версий
- Говорить, что именно система гарантирует при отказе узла и разрыве сети: кворум, выбор лидера, порядок событий, CAP и PACELC как формулировка выбора, а не как слоган
- Разводить путь чтения и путь записи и называть окно рассогласования каждой копии данных: проекции, CQRS, кэш и его инвалидация между сервисами
- Проектировать рост: stateless-слой, балансировку, шардирование с честным ключом, репликацию чтения и осознанную жизнь с лагом
- Делать систему наблюдаемой по устройству — сквозной контекст запроса через HTTP и брокер, метрики по RED и USE, SLO с бюджетом ошибок — и проверять архитектурную гипотезу до прода контрактом, внесённым отказом и нагрузочным профилем
- Проводить систему через изменение без простоя и записывать решения так, чтобы через полгода их можно было понять и оспорить по существу
О курсе
«Спроектируй службу доставки» — и через сорок минут у доски выясняется: код писать ты умеешь, а объяснить, почему здесь лог, а не очередь, сколько нужно RPS и что увидит клиент при сбое платёжки, — уже сложнее.
На работе то же самое: «вынеси уведомления в сервис» — и тебе решать, где провести границу, кому владеть данными и что делать с общими таблицами. А в существующей системе — отличать осознанное решение от наследия.
Сага, outbox, идемпотентность, итоговая согласованность — знакомые слова. Но курс учит не пересказывать паттерны, а выбирать их, считать цену и защищать решение.
Стартуем с монолита службы доставки. Затем ломаем два бесплатных допущения одного процесса: вызов не теряется и вызов мгновенен. Каждый паттерн появляется после конкретного сбоя: двойного списания, потерянного события, отставшего статуса или каскадного отказа.
Результат — собственный дизайн-док службы доставки. В нём будут требования и расчёты, границы сервисов и владельцы данных, контракты, поток событий, каталог отказов, SLO и ADR. Его можно принести на ревью, обсуждать с сеньором и использовать на секции system design.
Не «а теперь Kafka», а «какую проблему она решает». Сначала видишь отказ, затем разбираешь механизм, гарантии и цену. На стенде воспроизводишь разрывы сети, потерю ответов, выбор лидера, рассинхронизацию часов и повторную обработку событий.
Цифры вместо эпитетов. Считаем RPS, объём хранения, размер пула, бюджет задержки, хвосты веерных вызовов и доступность цепочек. «Надёжно» и «масштабируемо» без числа и способа проверки здесь не считаются требованиями.
Без привязки к языку. Подойдут Python, Go, Java, JavaScript, PHP и C#. В фокусе схемы, контракты, события, настройки и компромиссы — язык, на котором обсуждают архитектуру.
Микросервисы не продаются как цель. Модульный монолит — нормальный дефолт. Сервис появляется только когда названы причина, граница и цена. Курс поможет и понять, когда пора разделять систему, и увидеть, где существующий «зоопарк» — наследственная ошибка.
15 модулей: требования и расчёты → границы и данные → контракты → отказы и защиты → брокеры и события → согласованность → распределённые системы → CQRS и кэш → масштабирование → наблюдаемость и SLO → безопасность → изменения без простоя → системный дизайн вслух.
Стенд: Kafka, RabbitMQ, PostgreSQL, Redis, HTTP, gRPC, OpenTelemetry и Toxiproxy в Docker Compose. Не администрирование инструментов, а проверка архитектурных решений в условиях настоящих отказов.
Чего в курсе нет: фреймворков и ORM, внутренностей СУБД, Kubernetes, Terraform, CI/CD, администрирования брокеров и формальных доказательств. Это курс о том, как проектировать систему и отвечать за её поведение.
Курс автономен: проходить другие курсы линейки не нужно.
Для кого этот курс
Начальные требования
Что нужно знать
- Пишешь бэкенд-сервис на каком-либо языке: маршруты, обработчики, слои, зависимости.
- Понимаешь HTTP и REST на рабочем уровне: методы, коды ответов, тело запроса, заголовки.
- Работаешь с реляционной базой через ORM или SQL: таблицы, связи, транзакция как понятие.
- Запускаешь приложение в Docker и умеешь прочитать файл docker compose.
- Терминал: запустить команду, посмотреть логи, зайти в контейнер.
Что нужно на машине
- Ноутбук с Docker и Docker Compose: macOS, Linux или Windows с WSL2.
- Около 4 гигабайт свободной оперативной памяти на профиль стенда — тяжелее ни один модуль не требует.
- Терминал и git, чтобы забрать репозиторий стенда. Всё остальное приезжает образами по ходу курса.
- Аккаунт GitHub и Telegram: репозиторий стенда закрытый, доступ к нему выдаётся ученикам курса — через Telegram, на твой аккаунт GitHub. Он входит в курс: отдельно покупать или просить его не нужно.
Стенд при этом не пропуск, а усилитель: вывод каждой сцены приведён в самом шаге, поэтому курс читается и решается даже с телефона в метро, а запуск даёт то, чего чтением не получишь — руки на разорванной сети.
В этой же линейке есть входные курсы — по бэкенду на Python и по базам данных, — если из первого списка чего-то не хватает. Формально ни один из них не требуется: этот курс автономен и языку не учит.
Наши преподаватели
Как проходит обучение
Короткие шаги, каждый устроен одинаково: разбор механики, артефакт, вопрос, на который без разбора не ответишь.
Квизы-диагностики — основная проверяемая форма. Это не проверка памяти на термины. На входе всегда артефакт: timeline двух сервисов, лог повторов, трейс, порвавшийся о брокер, фрагмент контракта, набор метрик, конфигурация брокера. А вопрос звучит как «что окажется в базе», «почему сервис не встаёт после перезапуска», «где потерялся контекст запроса», «что вернуть клиенту сейчас». Неверный вариант — это типичная ошибка проектирования, а не глупость, и объяснение механики приходит вместе с ответом. Первая ошибка здесь обычно случается быстрее, чем ожидаешь, — это и есть самая честная проверка, не пересказ ли это докладов, которые ты уже смотрел.
Стенд на Docker Compose. Растёт вместе с курсом: начинается с монолита службы доставки и базы, к финалу это кластер из трёх брокеров, несколько сервисов, трейсинг и разрываемая сеть. Сцена запускается одной командой, в шаге сказано, что именно смотреть — какая команда, какой вывод, какое поле, — а результат наблюдения проверяется квизом. Сервисы внутри приходят готовыми образами: язык их реализации студента не касается. Сам стенд лежит в закрытом репозитории, и доступ к нему входит в курс: записался — репозиторий открывается на твой аккаунт GitHub, доплачивать и договариваться ни с кем не нужно.
Проектные шаги и дизайн-док. В конце модуля — не «повтори за автором», а спроектируй своё: проведи границу, выбери обмен, спроектируй поток событий, напиши ADR, защити решение. Шаг даёт шаблон раздела и критерии, по которым решение считается защищённым, а сразу за ним идёт квиз по этим критериям — чтобы проектный шаг оставил след, а не ощущение.
Чего здесь нет: задач с автопроверкой кода. Это осознанное решение, а не недоделка. Автопроверка на Stepik означала бы конкретный язык — то есть половину аудитории за бортом, — а курс языконезависим по устройству. Проверяемость держится на другом: квиз ловит ошибку рассуждения, стенд показывает поведение системы, дизайн-док остаётся у тебя как доказательство. Если тебе нужно «прошёл тесты — значит умею», честнее знать это до покупки.
Гильдия вайба — сообщество курса. Проходить в одиночку не обязательно, и здесь это особенно заметно: архитектурное решение нельзя проверить компилятором, его проверяют встречным вопросом. В Гильдию приносят не сломанный код, а схему — «нам говорят пилить, вот мой дизайн, где я не прав», — и получают ревью, которого на работе часто просто нет. Там же помощь по шагам, разбор чужих архитектур, поиск тиммейтов и общение с теми, кто идёт тем же путём. Правило простое: чем активнее участвуешь, тем больше берёшь от курса.
Программа курса
Что вы получаете
- Собственный дизайн-док службы доставки: требования и числа, карта границ с хозяевами данных, контракты, поток событий, каталог отказов, SLO, ADR. Документ, который можно принести на ревью и открыть на секции системного дизайна
- Каталог отказов «симптом — механика — защита — цена» — рабочая шпаргалка, по которой поломка называется за секунды, а не подбирается наугад
- Набор собственных ADR и навык писать их так, чтобы через полгода решение можно было понять и оспорить по существу — с названной альтернативой и названной ценой
- Отработанный формат системного дизайна вслух: порядок разбора, распределение времени, ответ на встречный вопрос — на двух полных разборах (распродажа билетов, маркетплейс с внешними продавцами) и на защите своего дизайна
- Стенд, который остаётся на твоей машине: монолит, брокеры, кластер из трёх узлов, разрываемая сеть. Доступ к репозиторию входит в курс и держится, пока ты на курсе, а склонированная копия — уже твоя: сцены можно перезапускать, когда тема всплывёт на работе
- Способность назвать вслух, что покупается, чем оплачивается и какая была альтернатива, — и выдержать три встречных вопроса, а не сдаться на первом
- Доступ в Гильдию вайба, который не кончается вместе с курсом: место, куда приносят архитектурное решение на ревью