Middle → Senior Engineering
16-недельная программа с преподавателем для middle-разработчиков: concurrency в Java, кэширование, обмен сообщениями через Kafka, resilience, консистентность данных, проектирование API, профилирование производительности, observability, глубокая безопасность, design doc/ADR и ревью чужого кода. Завершается сервисом, который вы проектируете, реализуете и защищаете, с письменным design doc. Это плановый силлабус, он может корректироваться под группу; гарантии трудоустройства нет.
Эта программа планируется и пока не стоит в расписании. Дата, группа и набор не объявлены, заявки мы не принимаем. Оставьте интерес или запросите консультацию: мы свяжемся с вами, когда программа будет запланирована.
- Длительность
- 16 недель
- Живые занятия
- 2 в неделю по 90 минут
- Структура
- Этапов: 4
16 недель
Программа по неделям
Это планируемая программа: порядок и глубина могут корректироваться под группу. Это не гарантия работы или должности.
01 · Недели 1–4
Concurrency, кэширование и производительность
Цель этапа: Понять модель concurrency в Java, locks против optimistic-подходов, virtual threads и кэширование; решать проблемы производительности через измерения и профилирование.
Неделя 1
Java concurrency: потоки, модель памяти, executor, virtual threads
- Race condition, visibility и happens-before (Java Memory Model)
- synchronized, volatile и atomic-классы
- ExecutorService, размер thread pool и CompletableFuture
- Virtual threads (Java 21): когда помогают, а когда нет
- Pinning, blocking I/O и включение virtual threads в Spring Boot
Лабораторная: Создать стресс-тестом race condition на общем счётчике и исправить через synchronized, atomic и lock; сравнить platform и virtual threads на 10 000 блокирующих задач.
Задание: Перевод денег между счетами: тест, воспроизводящий race, три подхода к исправлению (global lock, упорядоченные per-account locks, CAS) и отчёт с замерами; Pull Request.
Неделя 2
Locks, deadlock и optimistic concurrency
- ReentrantLock, ReadWriteLock, StampedLock и порядок захвата
- Deadlock, livelock, starvation: диагностика (thread dump)
- Optimistic vs pessimistic locking: JPA @Version и SELECT FOR UPDATE
- Lost update, write skew и lock-free подходы (CAS)
- Concurrent-коллекции и thread-safe дизайн: immutability
Лабораторная: Проанализировать thread dump намеренно зависающей программы и исправить; воспроизвести lost update на складе параллельными запросами и решить через @Version.
Задание: Решить oversell в сервисе бронирования оптимистично и пессимистично и написать короткий ADR со сравнением по throughput и числу retry; Pull Request.
Неделя 3
Кэширование: стратегии, инвалидация, stampede
- Cache-aside, read-through, write-through, write-behind
- Caffeine (in-process) vs Redis (distributed): trade-off
- TTL, инвалидация и жизнь с устаревшими данными
- Cache stampede, request coalescing и negative caching
- Абстракция Spring Cache и измерение hit rate
Лабораторная: Поставить дорогой запрос за кэш Caffeine, смоделировать stampede, затем решить подходом single-flight и измерить hit rate и задержку.
Задание: Добавить кэш в endpoint каталога товаров: решения по TTL и инвалидации, метрика hit rate и тест stampede; оформить решение как ADR; Pull Request.
Неделя 4
Профилирование производительности и нагрузочное тестирование
- Культура измерений: перцентили latency (p50/p95/p99), throughput, saturation
- JFR и async-profiler: профили CPU, allocation, locks
- Основы GC, heap dump и поиск утечки памяти
- Микро-бенчмарки на JMH и их ловушки
- Нагрузочное тестирование k6/Gatling и поиск bottleneck
Лабораторная: Профилировать медленный сервис через JFR, найти и устранить главный bottleneck и сравнить p95 до/после через k6.
Задание: Отчёт о производительности выданного сервиса: гипотеза, метод измерения, результат профиля, исправление, цифры до/после; Pull Request с исправлением кода.
Контрольная точка: Стресс-тест, воспроизводящий concurrency-баг, решение по стратегии кэша и исправление производительности, подтверждённое профилировщиком (замеры до/после).
02 · Недели 5–8
Обмен сообщениями и консистентность данных
Цель этапа: Применять на практике основы Kafka, паттерны outbox и idempotency, saga и уровни изоляции и понимать миф про 'exactly-once'.
Неделя 5
Основы Kafka: topic, partition, consumer group
- Модель лога: topic, partition, offset и гарантии порядка
- Producer: acks, retries, batching, партиционирование по ключу
- Consumer group, rebalance и стратегии commit offset
- Доставка at-most-once / at-least-once
- Spring Kafka и тестирование Kafka через Testcontainers
Лабораторная: Построить поток событий заказов на локальной Kafka; намеренно уронить consumer, чтобы увидеть повторную доставку, и показать сохранение порядка по ключу.
Задание: Сервис Order публикует события, сервис Notification их потребляет; тест на Testcontainers, доказывающий поведение at-least-once; Pull Request.
Неделя 6
Outbox, idempotency и мифы про 'exactly-once'
- Проблема dual-write: расхождение между БД и брокером
- Transactional outbox и relay (polling / CDC)
- Idempotent consumer: inbox-таблица и ключ дедупликации
- Idempotent producer и транзакции Kafka: что гарантируют и чего нет
- Poison message, retry topic и DLQ
Лабораторная: Воспроизвести баг dual-write (запись в БД есть, событие потеряно), исправить через outbox и показать идемпотентность consumer, отправив одно сообщение дважды.
Задание: Добавить outbox в Order и inbox/dedup в Notification; тесты отказов (relay падает, дубликат сообщения); короткое объяснение 'exactly-once'; Pull Request.
Неделя 7
Распределённые транзакции и saga
- Почему 2PC неудобен на практике и альтернативы
- Saga: orchestration vs choreography
- Компенсирующие действия и промежуточные состояния
- Состояние saga, timeout и идемпотентные шаги
- Наблюдаемость: видеть, где застряла saga
Лабораторная: Построить orchestrated saga для потока заказ → оплата → склад и показать компенсацию при сбое оплаты.
Задание: Документ с решением по saga/консистентности для capstone: какие операции требуют saga, а какие остаются локальными транзакциями; реализовать и протестировать одну saga; Pull Request.
Неделя 8
Консистентность данных: изоляция, read model и eventual consistency
- Уровни изоляции PostgreSQL и аномалии (non-repeatable read, write skew)
- Serializable с retry; advisory lock
- CQRS-lite: read model и проекции
- UX при eventual consistency: read-your-writes
- Обнаружение расхождений и reconciliation-задачи
Лабораторная: Воспроизвести аномалию write skew двумя параллельными транзакциями и предотвратить её через SERIALIZABLE или constraint.
Задание: Построить read model (проекцию) из событий заказов, протестировать его пересборку и reconciliation-задачу; Pull Request.
Контрольная точка: Поток из двух сервисов с outbox и idempotent consumer, тесты сценариев отказов и заметка с решением по saga.
03 · Недели 9–12
Resilience, дизайн API и observability
Цель этапа: Сделать сервис устойчивым к отказам зависимостей, развивать API через версионирование и измерять систему метриками, tracing и SLO.
Неделя 9
Resilience: timeout, retry, circuit breaker
- Timeout на каждом вызове: connect, read и общий deadline
- Retry: exponential backoff, jitter и retry budget
- Circuit breaker: состояния и настройка (Resilience4j)
- Bulkhead и изоляция зависимостей
- Ложная безопасность fallback и degraded-режим
Лабораторная: Смоделировать медленную зависимость (WireMock delay), увидеть retry storm и стабилизировать через timeout + backoff + circuit breaker.
Задание: Сделать вызов платёжного провайдера устойчивым: timeout, retry budget, circuit breaker, idempotency key; тесты отказов; Pull Request.
Неделя 10
Backpressure, rate limiting и load shedding
- Очереди и закон Литтла: почему задержка взрывается
- Bounded queue, backpressure и lag consumer в Kafka
- Алгоритмы rate limiting: token bucket, sliding window
- Load shedding и приоритизация
- Пределы autoscaling и capacity planning
Лабораторная: Довести сервис с неограниченной очередью под нагрузкой до исчерпания памяти, затем исправить bounded queue и ответами 429.
Задание: Добавить в сервис token-bucket rate limiter и load shedding; k6-тест, показывающий принятые и отклонённые запросы; Pull Request.
Неделя 11
Проектирование API, версионирование и контракты
- Моделирование ресурсов, идемпотентные методы и Idempotency-Key
- Пагинация, фильтрация, ETag и условные запросы
- Модель ошибок: RFC 9457 problem details
- Версионирование: URL, header, additive-эволюция и deprecation
- Contract testing (Spring Cloud Contract / Pact) и OpenAPI
Лабораторная: Внести breaking change в API и сломать клиента, затем сделать то же изменение безопасно через additive-эволюцию и contract-тест.
Задание: OpenAPI-документ capstone API, политика версионирования/deprecation и consumer contract-тест; Pull Request.
Неделя 12
Observability: метрики, tracing и SLO
- Три столпа: логи, метрики, трейсы и их связь
- Методы RED/USE и хороший дизайн метрик (cardinality)
- Distributed tracing с OpenTelemetry
- SLI, SLO, error budget и осмысленные alert
- Dashboard и runbook для on-call
Лабораторная: Настроить трейс OpenTelemetry между двумя сервисами и найти по нему медленный вызов; написать burn-rate alert на основе SLO.
Задание: Определения SLI/SLO, JSON dashboard, правила alert и runbook для capstone-сервиса; Pull Request.
Контрольная точка: Сервис, остающийся в пределах SLO в chaos-сценарии (медленная/упавшая зависимость), решение по версионированию API и определение dashboard + alert.
04 · Недели 13–16
Безопасность, проектные решения, менторство и capstone
Цель этапа: Применять безопасность в глубину, письменно обосновывать trade-off через design doc/ADR, ревьюить чужой код и менторить, а также защитить capstone-сервис.
Неделя 13
Глубокая безопасность: threat modeling и defense in depth
- Threat modeling: STRIDE и trust boundary
- OAuth2/OIDC, ловушки JWT и ротация токенов
- Авторизация на уровне ресурса и утечки multi-tenancy
- Управление секретами, supply chain и сканирование зависимостей
- Audit log, rate limiting и дизайн против злоупотреблений
Лабораторная: Провести 45-минутную сессию STRIDE threat modeling выданного сервиса, выбрать 5 самых рискованных угроз и написать exploit-тест для одной.
Задание: Документ threat model для capstone и реализация не менее 3 мер безопасности с тестами авторизации; Pull Request.
Неделя 14
Design doc, ADR и анализ trade-off
- Структура design doc: контекст, цели/не-цели, альтернативы
- Написание ADR: решение, обоснование, последствия
- Анализ trade-off: матрицы решений и обратимость
- Оценка: расчёты capacity и прикидки на салфетке
- Design review: задавать вопросы и защищать ответы
Лабораторная: За 15 минут отревьюить выданный design doc, записать 5 ключевых вопросов и 2 риска, затем выслушать ответы автора на защите.
Задание: Написать design doc capstone-сервиса (2–4 страницы) и не менее 3 ADR; отправить на peer review (Pull Request).
Неделя 15
Ревью чужого кода, менторство и реализация capstone
- Review уровня senior: дизайн, риск, пробелы тестов
- Язык обратной связи: вопрос vs указание, blocking vs nit
- Менторство junior: pair programming и делегирование задач
- Технический долг: оценка и переговоры
- Реализация capstone: вертикальные срезы, feature flag
Лабораторная: Отревьюить Pull Request junior-коллеги (разделяя blocking и nit) и провести 30-минутную сессию pair programming.
Задание: Основная часть реализации capstone (включая тесты, observability, безопасность) и письменные review двух Pull Request коллег; Pull Request.
Неделя 16
Защита capstone
- Финальные испытания сервиса: chaos, нагрузка, безопасность
- Обновление design doc: что изменилось и почему
- 20-минутная защита: демо, trade-off, измерения
- Вопросы и ответы: защита дизайна перед комиссией
- Ретроспектива и план роста до уровня senior
Лабораторная: Провести финальные chaos- и нагрузочные тесты и добавить результаты в design doc; пробная репетиция защиты.
Задание: Итоговый репозиторий (код, тесты, design doc, ADR, runbook), 20-минутная защита и заметка самооценки.
Контрольная точка: Design doc, реализованный сервис (тесты, observability, безопасность), не менее 3 ADR и 20-минутная защита.