Защита проекта

Перед началом: все модули пройдены, мессенджер работает на вашем домене. Инструменты: ваш проект, два устройства, спокойный голос. Трудоёмкость: ~4 ч подготовки.

🔥 Инцидент: «На защите всё упало»

Классика жанра: студент показывает проект с одного ноутбука — прекрасно. Комиссия просит «а покажите с двух устройств» — и оказывается, что второй пользователь был только в голове автора: WS-клиент в одной вкладке, уведомления не настроены, а на вопросе «почему у вас seq, а не created_at?» отвечать нечем — решение было скопировано, а не принято. Защита — это не проверка «работает ли», а проверка «понимаете ли вы, что построили». Этот модуль — регламент сдачи: чек-лист, ADR, демо-сценарий, вопросы.

📖 Что проверяет защита

13.1 Чек-лист приёмки

Функциональность (демонстрируется живьём):

  • Личные диалоги: старт переписки из контактов, непрочитанные, read-receipts
  • Группы: создание, роли, добавление/удаление, системные сообщения, инвайт по ссылке
  • Отправка: оптимистичная запись, статусы sending → sent → read, повтор при ошибке
  • Реальное время: доставка на два устройства, typing, присутствие
  • Синхронизация: закрыть вкладку получателя, отправить сообщения, открыть — лента без потерь
  • Уведомления: push офлайн-получателю в direct; mute гасит, mention пробивает
  • Приватность: чужой диалог недоступен (проверяется curl-ом за другого пользователя)

Инженерное качество:

  • make test и make validate-api зелёные
  • Миграции в expand-стиле; откат релиза проверен
  • /metrics отдаёт набор метрик; есть отчёт нагрузочного теста
  • README проекта: как поднять, как выкатить, где смотреть метрики/логи

Эксплуатация:

  • HTTPS + wss:// на вашем домене
  • Бэкап настроен и восстановление проверено
  • Релизный конвейер: build-push → release.sh → гейт (история тегов видна)

13.2 ADR: решения, которые вы обязаны защитить

По каждому — проблема, варианты, выбор, цена. Минимум семь:

№РешениеКлючевой аргументЦена, которую признаёте
1Единая conversations для direct и group80% логики общиеnullable-поля, CHECK-инварианты
2Канонический direct_key + UPSERTгонка лечится БД, не кодомключ-суррогат в схеме
3seq на диалог вместо created_atдетерминированный порядок, курсорыдыры в нумерации
4Sync по seq после реконнектапотерь нет, транспорт — не гарантиясложность клиента
5At-least-once + дедуп по id«ровно раз» недостижимоклиент обязан дедуплицировать
6Presence/typing в Redis TTL«вечных онлайн» не бываетфичи гаснут при падении Redis
7Сборка вне VM, теги в .env, гейтоткат в одну командусвой конвейер вместо «docker build на сервере»

13.3 Демо-сценарий (репетировать, не импровизировать)

  1. Вход Алисы на ноутбуке, Боба — на телефоне.
  2. Боб печатает первым: Алиса видит typing, затем сообщение и бейдж.
  3. Алиса открывает диалог — у Боба галочка «прочитано».
  4. Создают группу, добавляют Кэрол — системное сообщение у всех трёх.
  5. Боб выключает связь (авиарежим), Алиса пишет три сообщения, Боб возвращает связь — лента догоняет без потерь, без дублей.
  6. Боб ставит mute; Кэрол пишет в группу — пуша нет; Кэрол пишет @bob — пуш приходит.
  7. Показ эксплуатации: https://домен, история выкатов, откат (заранее записанный), восстановление бэкапа (можно показать лог).

13.4 Вопросы, к которым готовимся

  • «Почему seq, а не timestamp?» — покажите инцидент равных миллисекунд.
  • «Что будет, если Redis упадёт в проде?» — деградация украшений, ядро живёт (Модуль 7).
  • «Сообщение может прийти дважды?» — да, at-least-once; дедуп по id.
  • «Как выкатите срочный фикс?» — тег → build-push → release.sh → гейт; откат — тег назад.
  • «Где узкое место вашей системы?» — честный ответ из отчёта Модуля 11 (обычно sync при шторме и пул БД), плюс что уже сделано.

💻 Практика

  1. Пройдите чек-лист §13.1 у себя на стенде до защиты — каждая галка проверена руками, а не «наверное работает».

  2. Напишите docs/adr/ — по одному файлу на решение из §13.2 в вашем стиле: контекст → варианты → решение → последствия.

  3. Отрепетируйте демо §13.3 дважды: второй прогон — «на время» (10 минут).

  4. Подготовьте ответы на §13.4 на своих цифрах (p99, число коннектов, лаг outbox — из отчёта Модуля 11).

  5. Соберите README-финал: скриншот списка диалогов и группы, схема архитектуры, команды эксплуатации.

Критерии оценки (для самопроверки и комиссии):

УровеньЧто видно
ЗачётРаботает P2P и группы; sync без потерь; деплой на домене
ХорошоПлюс receipts, typing, присутствие, уведомления с правилами; тесты и метрики
ОтличноПлюс нагрузочный отчёт с анализом, откат и бэкап проверены, ответы опираются на цифры

🧩 Quiz

1. Комиссия просит «покажите синхронизацию». Какой сценарий — канонический?
2. Бэкап «проверен», если…
3. Почему демо-сценарий надо репетировать на двух реальных устройствах?
4. Зачем ADR, если код уже написан?
5. «Что будет, если Redis упадёт?» — верный ответ?

✅ Итоги модуля

  • Чек-лист приёмки разделяет «функциональность / инженерия / эксплуатация» — по нему видно уровень проекта.
  • Семь ADR покрывают все ключевые решения курса — и их цену.
  • Демо-сценарий отрепетирован на двух устройствах и укладывается в 10 минут.
  • Ответы на каверзные вопросы опираются на собственные цифры и инциденты модулей.
  • Мессенджер живёт, откатывается и восстанавливается — курс пройден.

🔗 Куда дальше

Трек развивается: следующий курс — микросервисная эволюция мессенджера (вынос ws-gateway в отдельный сервис, Redis Streams между репликами, независимые деплои). Всё, что нужно, уже заложено в этом курсе: outbox, интерфейс брокера, seq-контракт и релизный конвейер — продолжение вы узнаете при первых словах лекции.