Microservices и System Design
16-недельная программа с преподавателем для работающих Java/backend-инженеров: компромиссы архитектуры, DDD, Kafka, outbox и саги, PostgreSQL под нагрузкой, Kubernetes, AWS Well-Architected, наблюдаемость и инженерия с AI. Весь курс вы развиваете одну распределённую систему и защищаете её рабочим кодом, ADR, нагрузочным тестом и сценарием отказа. Это планируемый силлабус, он может адаптироваться под группу; гарантии трудоустройства нет.
- Длительность
- 16 недель
- Живые занятия
- 2 в неделю по 90 минут
- Структура
- Этапов: 4
- Язык
- Азербайджанский или английский (в зависимости от группы)
- Нагрузка в неделю
- Планируйте не менее 6 часов практики в неделю вместе с лабораторными
- Как завершается
- Архитектурная защита с ADR, нагрузочным тестом и сценарием отказа
Система, которую вы строите весь курс
Одна распределённая система, шестнадцать недель
Вы шаг за шагом развиваете платформу продажи билетов. Выберите паттерн: какую проблему он решает, как ломается и на какой неделе изучается.
Проблема
Запись заказа и публикация события должны пройти вместе.
Как ломается
Брокер недоступен и событие теряется, или дубль сообщения отправляет два уведомления.
Изучается
Неделя 7
Диаграмма показывает учебную систему курса (не реальную компанию). Лабораторные по Kubernetes — на бесплатном локальном кластере (kind/k3d); AWS изучается без создания платных ресурсов.
О программе
Для кого
Java backend-разработчики (junior+ и middle) и выпускники Java & Backend Engineering, которые хотят проводить границы сервисов, надёжно связывать сервисы и обосновывать решения system design.
Требования
- Пишете REST API на Spring Boot
- Работали с SQL, транзакциями и JPA
- Основы Git, тестов и Docker
Технологии
- Java 21
- Spring Boot
- PostgreSQL, Flyway
- Kafka
- Outbox, саги, CQRS
- OpenAPI, контрактные тесты
- Resilience4j
- Redis
- OpenTelemetry, Micrometer
- Docker, CI/CD
- OAuth2/OIDC
Как завершается
- Контрольные точки этапов: два сервиса с картой контекстов и контрактным тестом; outbox, идемпотентный потребитель и сага; нагрузочный тест, трассы, SLO и план отката
- Итог: построенная вами система сервисов с дизайн-документом, ADR, сценарием инцидента и технической защитой по рубрике
Менторство и обратная связь
Живые занятия ведёт преподаватель; каждое еженедельное задание проверяется по рубрике на 100 баллов с письменным отзывом. В конце каждого этапа — контрольная точка, слабые места видны заранее.
16 недель
Программа по неделям
Это планируемая программа: порядок и глубина могут корректироваться под группу. Это не гарантия работы или должности.
01 · Недели 1–4
Основы архитектуры
Цель этапа: Начать с атрибутов качества: решать, когда и как делить систему, защищать контракты и управлять базой под нагрузкой.
Неделя 1
Архитектура, атрибуты качества и компромиссы
- Атрибуты качества: доступность, задержка, изменяемость, стоимость
- Модульный монолит и микросервисы: когда не делить
- ADR и диаграммы C4
- Система на весь курс: распределённая платформа продажи билетов
Лабораторная: Нарисовать диаграммы C4 (контекст и контейнеры) учебного монолита и описать сценарии для двух атрибутов качества.
Задание: ADR: остаться монолитом или выделить модуль — с обоснованием и альтернативами.
Неделя 2
Domain-driven design и декомпозиция сервисов
- Единый язык, ограниченные контексты, карта контекстов
- Агрегаты и инварианты
- Владение данными: база на сервис
- Постепенное выделение по шаблону strangler fig
Лабораторная: Event storming: найти контексты, агрегаты и владельцев данных платформы билетов.
Задание: Карта контекстов и план выделения первого сервиса по шаблону strangler fig.
Неделя 3
Контракты сервисов: REST, gRPC и асинхронное взаимодействие
- Синхронно или асинхронно: связность и отказы
- Contract-first с OpenAPI и gRPC
- Версионирование и обратная совместимость
- Consumer-driven контрактные тесты и API Gateway
Лабораторная: OpenAPI-контракт выделенного сервиса, маршрут в шлюзе и контрактный тест, который его охраняет.
Задание: Выпустить новую версию, не ломая контракт; показать, что CI ловит ломающее изменение.
Неделя 4
PostgreSQL под нагрузкой: запросы, изоляция и блокировки
- EXPLAIN ANALYZE и проектирование индексов
- Уровни изоляции, блокировки и взаимоблокировки
- Пул соединений (HikariCP) и его исчерпание
- Миграции без простоя
Лабораторная: Воспроизвести медленный запрос и взаимоблокировку под нагрузкой, измерить и исправить.
Задание: Отчёт о производительности с замерами до/после и обратимая миграция.
Контрольная точка: ADR, C4, карта контекстов, контрактный тест и измеренное исправление производительности.
02 · Недели 5–8
Распределённые данные и события
Цель этапа: Связать сервисы через Kafka без потерь и двойной обработки и осознанно выбирать согласованность.
Неделя 5
Основы распределённых систем
- Репликация и партиционирование
- Модели согласованности и заблуждения о CAP
- Семантика доставки и порядок
- Обнаружение отказов и координация
Лабораторная: Смоделировать сетевую задержку и разделение сети и понаблюдать за поведением двух реплик.
Задание: Таблица требований к согласованности для каждой операции системы с обоснованием.
Неделя 6
Kafka и событийные системы
- Партиции, группы потребителей, офсеты и ребалансировка
- Гарантии доставки и идемпотентный продюсер
- Эволюция схем и контракты событий
- Ретраи, dead-letter топики и отставание потребителей
Лабораторная: Лаборатория отказов: медленный потребитель копит отставание и вызывает шторм ребалансировок — диагностика и исправление.
Задание: Контракт события, политика dead-letter и порог оповещения по отставанию.
Неделя 7
Outbox, идемпотентность и саги
- Проблема двойной записи и транзакционный outbox
- Идемпотентный потребитель
- Саги: хореография и оркестрация, компенсация
- Альтернативы распределённым транзакциям
Лабораторная: Сага заказ → оплата → бронь места; ни одно событие не теряется, пока брокер недоступен.
Задание: Тесты поведения в каждой точке отказа и диаграмма состояний саги.
Неделя 8
CQRS, event sourcing и кэширование
- Модели чтения и как показать eventual consistency пользователю
- Event sourcing: когда оправдан, а когда нет
- Стратегии кэширования в Redis и инвалидация
- Cache stampede и согласованность
Лабораторная: Построить модель чтения из событий, перестроить её с нуля и измерить кэш под нагрузкой.
Задание: ADR: использовать event sourcing или нет — для одного контекста системы.
Контрольная точка: Outbox, идемпотентный потребитель, сага с компенсацией, модель чтения и лаборатория отказов Kafka.
03 · Недели 9–12
Cloud-native эксплуатация
Цель этапа: Сделать систему устойчивой, развернуть и отладить её в Kubernetes, наблюдать и управлять инцидентами.
Неделя 9
Отказоустойчивость и производительность
- Бюджеты таймаутов, ретраи и backoff с jitter
- Circuit breaker и bulkhead
- Backpressure, rate limiting и сброс нагрузки
- Нагрузочное тестирование и поиск узких мест
Лабораторная: Лаборатория отказов: медленная зависимость вызывает шторм ретраев — защитить Resilience4j и лимитами, доказать на k6.
Задание: Результаты нагрузочного теста, обоснование лимитов и отчёт об инциденте.
Неделя 10
Контейнеры и Kubernetes I
- OCI-образы и безопасный Dockerfile
- Архитектура Kubernetes: control plane, узлы, поды
- Deployment, Service, Ingress/Gateway
- ConfigMap, Secret, пробы, requests и limits
Лабораторная: Развернуть сервисы в локальном кластере kind/k3d и отладить сломанную пробу (бесплатно, на своём компьютере).
Задание: Манифесты, обоснование лимитов ресурсов и заметки по отладке.
Неделя 11
Kubernetes II: релизы, масштабирование и безопасность
- Rolling update, откат и стратегии релизов
- HPA и автомасштабирование
- Helm, пространства имён и принципы GitOps
- RBAC, network policy и безопасность кластера
Лабораторная: Лаборатория отказов: неверно настроенный rollout — обнаружить, откатить и исправить Helm chart.
Задание: Helm chart, network policy и runbook отката.
Неделя 12
Наблюдаемость и эксплуатация
- OpenTelemetry: трассы, метрики, логи
- Prometheus, Grafana и проектирование оповещений
- SLI, SLO и error budget
- Управление инцидентами, RCA и runbook
Лабораторная: Лаборатория отказов: регрессия задержки находится по трассам; RCA нарушения SLO.
Задание: Дашборд, SLO, два оповещения и blameless postmortem.
Контрольная точка: Нагрузочный тест, Helm chart, runbook отката, SLO и postmortem.
04 · Недели 13–16
Облачная архитектура, AI и итоговый проект
Цель этапа: Обосновывать облачные решения и безопасность, критически использовать AI и защитить систему.
Неделя 13
AWS и облачная архитектура (Well-Architected)
- VPC, IAM и основы сетей
- EKS, RDS и управляемые очереди: что и когда
- Высокая доступность, disaster recovery и секреты
- Управление затратами и Well-Architected review
Лабораторная: Целевая архитектура системы в AWS, политики IAM и расчёт месячной стоимости (без создания платных ресурсов).
Задание: Ревью по столпам Well-Architected и план DR (RPO/RTO).
Неделя 14
System design: метод и архитектура безопасности
- Требования, оценка ёмкости и масштабирование
- Проектные решения с партиционированием и кэшем
- Моделирование угроз, идентичность сервисов и OAuth2/OIDC
- Дизайн-ревью: защита компромиссов
Лабораторная: Живое дизайн-ревью с ментором: дизайн-документ итогового проекта.
Задание: Дизайн-документ: требования, ёмкость, C4, модель угроз и ADR.
Неделя 15
Инженерия с AI: Claude Code, ревью и риски
- Агентные процессы, инструкции проекта и концепции MCP
- Тесты и код-ревью с AI — проверка результата
- Prompt injection, утечки данных и границы одобрения человеком
- Стоимость, дисциплина токенов и воспроизводимая оценка
Лабораторная: Сделать фичу и тесты с Claude Code; найти и доказать минимум два дефекта в коде, написанном AI.
Задание: Политика использования AI: какие задачи, какие проверки, какие данные никогда не отправляются.
Неделя 16
Итоговый архитектурный проект и техническая защита
- Рабочие сервисы, асинхронные сообщения и стратегия согласованности
- Манифесты развёртывания, мониторинг и автотесты
- Нагрузочные тесты, симуляции отказов и ревью безопасности
- Расчёт стоимости, ADR и защита
Лабораторная: Живое демо и поведение системы в сценарии отказа, заданном ментором.
Задание: Итоговая техническая защита по рубрике (и реализация, и архитектурное обоснование).
Контрольная точка: Дизайн-документ, расчёт стоимости, политика использования AI и итоговая защита по рубрике.