1. Вступление ~ 5 мин.
1.1. Приветствие (кто я и почему могу на эту тему говорить), про мой опыт.
1.2. О чем сегодня поговорим (план доклада)

2. Основная часть ~ 35 мин.
2.1. Предыстория и начало: потребность в сервисе и какой контекст
Контекст создания сервиса, выпиливания из монолита и бизнес-требования
Технические требования к сервису
Данные по нагрузке: сколько событий из топика обрабатываем, сколько рассылаем пушей и смс
2.2. Элементарный сервис уведомлений
Сервис уведомлений, если у нас бы не было внешних зависимостей.
2.3. Требование #1 — сервис должен позволять быстро разрабатывать и подключаться к любому значимому доменному событию.
Модуль 1. Добавляем анализ входящих потоков событий. Модель реакции на события из внешних систем, позволяющая определять необходимость этих событий без доработок или с минимальными доработками в мастер-системах (входящий поток).
Модуль 2. Унификация внутренних событий (исходящий поток).
2.4. Требование #2 — необходим функционал настройки уведомлений по типу заказа, типу доставки, типу продавца, а также
Модуль 3. Кубик маппинга.
Модуль 4. Рендеринг. Добавляем возможность гибкой шаблонизации сообщений.
2.5. Требование #3 — в сервисе необходимо изолировать от основных процессов все тяжелые синхронные запросы в соседние системы.
Модуль 5. External Data Provider (XDP).
2.6. Требование #4 — легко встраивать новые транспорты сообщений.
Модуль 6. Отдельный сервис для транспортной инфраструктуры уведомлений. Основной поинт - эта функциональность не является частью сервиса уведомлений.
2.7. Требование #5 — рассылку сообщений можно осуществлять только в определенное время.
Модуль 7. Шедулинг. Буфер со скользящим указателем.
2.8. Требование #6 — возможность экономии денег через каскад транспортов с эскалацией их стоимости, смс VS пуши.
Модуль 8. План отправки (Delivery Plan).
2.9. Стек технологий:
Модуль 9. Golang, Postgres, Kafka, RabbitMQ, буфер через Redis (Range by Score) с репликацией в БД.
2.10. Модульный монолит. Финальная архитектура сервиса.

3. Заключение ~ 5 мин.
3.1. Подводные камни в реализации такого сервиса:
не доверять любой системе вне основного контекста сервиса, всегда закладывать принцип ретраев, учитывать влияние ретраев на основной флоу процессинга (переотправка через транспорт должна идти через шэдулинг); почему ретраи без Circuit Breaker
система экспериментов (тегирование) для заказов – не была предусмотрена. Ввод уведомлений в эксплуатацию через эту систему добавил синхронную зависимость от внешних сервисов в момент обработки события от Кафки. Соответственно появилась необходимость асинхронно получать данные об экспериментах заказов из внешних сервисов не тормозя обработку событий из кафки.
выбор режима работы буфера - быстро или надёжно (лучше быстро, но с высоким SLA, плюс дополнительный механизм, позволяющий автоматически выявлять проблемные события или сообщения и восстанавливать их работу)
дедубликация событий из кафки на Редисе должна учитывать производительность механизма expiration (¼ от максимальной производительности по документации)

3.2. Графики, статистика используемых ресурсов, сокращение расходов (если согласуют).
3.3. Коротко выводы.

4. Вопросы и ответы
4.1. Открытые вопросы и дискуссия по теме доклада.
4.2. Примеры и дополнительные вопросы из аудитории.