Архитектура распределённых систем
Курс по архитектуре распределённых систем для Senior-разработчиков на Go. Одно-трековый: только Go. Студент проходит путь от прототипа до production-ready системы, применяя каждый паттерн как ответ на конкретную боль роста.
Философия курса
Паттерн — это ответ на боль роста, а не самоцель. Мы не изучаем Outbox ради Outbox. Мы изучаем Outbox, когда проект дорос до интеграций, и события начали теряться. Мы не изучаем Saga ради Saga — мы изучаем Saga, когда шаги распределённого процесса начали зависать на полпути.
Один проект растёт сквозь все модули. Каждый модуль — это новая стадия зрелости одного и того же проекта. Студент не переключается между разрозненными примерами, а наблюдает, как растёт и усложняется система.
Четыре архетипа проектов. Один и тот же паттерн проявляется по-разному в разных типах систем:
- Финтех (P2P) — основной сквозной пример (CP, идемпотентность, Saga, аудит)
- Git-хостинг — практический курс-территория (POSIX, стриминг, bulkhead, saga-merge)
- Мессенджер — real-time, доставка, офлайн (AP, очереди)
- Лента / чтение — AP, кэш, шардирование, eventual consistency
Цель курса
Вырастить инженера, который:
- Осознанно выбирает компромиссы (trade-offs) и фиксирует их в ADR с количественными метриками
- Понимает, когда нужен паттерн (признаки боли роста), а не только как его реализовать
- Проектирует отказоустойчивые распределённые системы на Go поверх Yandex Cloud
- Управляет распределёнными транзакциями (Outbox, Saga), гарантирует идемпотентность
- Планирует деградацию и эволюцию инфраструктуры
- Измеряет качество системы через SLO, Error Budget и алерты
Формат
Модульный, проектный, с Code Review и защитой архитектуры. Каждый модуль: инцидент → теория → практика → антипаттерн → чек-лист → мостик.
Длительность
3–6 месяцев, 15–25 часов в неделю.
Результат
- Production-ready система (Capstone)
- Набор из 8+ ADR с количественными Trade-offs
- Отчёт по SLO, Error Budget и стоимости
- Стратегия миграции и эволюции
- Защита архитектуры перед «комитетом» (CTO/техлид/финдиректор)
Стек
Только Go 1.22+ (без альтернативных треков).
Инфраструктура
Yandex Cloud (Managed PostgreSQL, YDB Serverless, ALB, Lockbox, Message Queue / Kafka, Object Storage, NFS, Cloud Functions), Terraform (IaC), OpenTelemetry, Prometheus, Jaeger.
Сквозные требования
- Clean Architecture & DDD (Handler → Use Case → Repository → Adapter)
- Интеграционные тесты с Toxiproxy (сбои сети/БД)
- Нагрузочные тесты k6 (p99 latency, error rate, throughput)
- Структурированные логи с
trace_idиtenant_id - API-контракты с NFR (SLO, RTO, допустимая деградация)
- Явная fallback-стратегия для каждого внешнего вызова
Место в экосистеме курсов
| Курс | Роль | Связь |
|---|---|---|
| Git Hosting: Serverless MVP | Входная точка: практика, cost-first, ~50₽/мес | Использует паттерны из этого курса на упрощённом стеке |
| Этот курс | Карта мира: паттерны как ответы на боли роста | Теория и практика на полном стеке |
| Git Hosting: от 10k до 100k RPS | Территория на масштабе | Применяет паттерны к Git-хостингу при росте |
Рекомендуемый порядок (по желанию, курс самодостаточен): Serverless MVP → этот курс → Highload.
Модули: стадия роста → боль → паттерн
| # | Стадия роста | Боль | Паттерн-лекарство | Сигнал «пора изучать» |
|---|---|---|---|---|
| 1 | Идея / прототип | «как не нагородить» | Trade-offs, ADR, CAP/PACELC | Проект ещё не написан |
| 2 | MVP / первые юзеры | «дубли при ретраях» | Идемпотентность, Idempotency-Key | Клиент присылает один запрос дважды |
| 3 | Интеграции | «события теряются» | Transactional Outbox, Dual-Write | Событие не дошло до соседа |
| 4 | Сложные процессы | «шаги зависают на полпути» | Saga, компенсации | Деньги списаны, товар не зарезервирован |
| 5 | Внешние сервисы тормозят | «сосед тормозит — мы легли» | CB, Bulkhead, кэш | p99 вырос из-за чужого таймаута |
| 6 | Продакшен 24/7 | «не видно, что ломается» | OTel, SLO, Error Budget | Инцидент расследуется > 1 часа |
| 7 | Публичный API | «атаки, утечки» | JWT, RBAC, HMAC, секреты | Утечка секрета / данных |
| 8 | Рост нагрузки ×10 | «как это всё развернуть» | IaC, Docker, K8s vs Serverless | p99 > SLO при росте |
| 9 | Рост нагрузки ×10 | «БД и диск упираются» | PgBouncer → CQRS | write CPU > 80% на мастере |
| 10 | Зрелость | «как доказать надёжность» | Chaos, Cost Awareness | CFO спрашивает: «почему так дорого?» |
| 11 | Защита | «обосновать перед комитетом» | Capstone, ROI, миграция | Комитет задаёт «почему не Y» |
| 12 | Приложение | — | Инструменты архитектора | — |
Сквозные требования к ADR
Каждый ADR в курсе содержит:
- Контекст и альтернативы (мин. 2)
- Решение с количественными метриками (₽/мес, p99, RTO, % риска)
- План миграции / отката
- Связь с другими модулями
Критерий сдачи курса: студент заполняет сводную таблицу Trade-offs своими цифрами и защищает каждое решение перед комитетом — без единого «потому что так принято».