Эволюция саг на примере платежной системы: как не ошибиться с выбором?
Доклад отозван
Целевая аудитория
Тезисы
Все, кто реализовывал или пытался реализовать саги, сталкивался с множеством технических выборов. А для тех, кто только планирует или не очень доволен получившимся решением, я хочу рассказать про эволюцию подходов к реализации саг в нашей системе: как менялись требования с ростом системы и как это изменяло наши саги.
Через призму этой эволюции в своем докладе хочу попробовать ответить на такие вопросы:
* Как сделать саги действительно асинхронными, чтобы не боятся резких пиков нагрузки и отказов частей системы?
* Зачем в сагах использовать брокер сообщений? Или можно обойтись базой данных и http-взаимодействиями?
* Как и зачем разбивать чересчур длинные саги на несколько? — Посмотрим через призму ограниченных контекстов (DDD) и нефункциональных требований.
* У саг обычно есть "контекст" — для каких саг это выделенная бизнес-сущность, а для каких временные данные?
* Чем в реализации саг может помочь Event Sourcing?
* Какие решения есть для гарантий, что сага не зависнет посередине?
Архитектор, более 15 лет стажа в IT, более 10 лет проектирования доменах: FinTech, GameDev, MedTech и транспорт.
ЕДИНЫЙ ЦУПИС
Видео
Другие доклады секции
Архитектуры и масштабируемость