Эволюция саг на примере платежной системы: как не ошибиться с выбором?

Архитектуры и масштабируемость

Платёжные системы, обработка платежей
Микросервисы, SOA
Отказоустойчивость
Распределенные системы
Микросервисы

Доклад отозван

Целевая аудитория

Senior/техлиды/архитекторы, которым выпало реализовывать саги.

Тезисы

Все, кто реализовывал или пытался реализовать саги, сталкивался с множеством технических выборов. А для тех, кто только планирует или не очень доволен получившимся решением, я хочу рассказать про эволюцию подходов к реализации саг в нашей системе: как менялись требования с ростом системы и как это изменяло наши саги.

Через призму этой эволюции в своем докладе хочу попробовать ответить на такие вопросы:
* Как сделать саги действительно асинхронными, чтобы не боятся резких пиков нагрузки и отказов частей системы?
* Зачем в сагах использовать брокер сообщений? Или можно обойтись базой данных и http-взаимодействиями?
* Как и зачем разбивать чересчур длинные саги на несколько? — Посмотрим через призму ограниченных контекстов (DDD) и нефункциональных требований.
* У саг обычно есть "контекст" — для каких саг это выделенная бизнес-сущность, а для каких временные данные?
* Чем в реализации саг может помочь Event Sourcing?
* Какие решения есть для гарантий, что сага не зависнет посередине?

Михаил Натаров

ЕДИНЫЙ ЦУПИС

Архитектор, более 15 лет стажа в IT, более 10 лет проектирования доменах: FinTech, GameDev, MedTech и транспорт.

ЕДИНЫЙ ЦУПИС

ЕДИНЫЙ ЦУПИС – это высоконагруженный fintech с SLA 99,99, более чем 12 000 000 пользователей и более чем 500 релизами в квартал. ЕДИНЫЙ ЦУПИС — команда, в которой важен каждый. Команда с прозрачной и приятной корпоративной культурой, в которой ценят профессионалов и создают удивительные по своей технологичности и сложности вещи быстро и эффективно.

Видео

Другие доклады секции

Архитектуры и масштабируемость