Компенсации - это не просто отмена предыдущих шагов. Это новый бизнес-процесс, который требует тщательного проектирования. Перед разработчиками встают сложные вопросы:
- Как и когда откатывать изменения?
- Всегда ли нужно возвращать все затронутые данные в исходное состояние?
- И самое главное, как объяснить это пользователю?
Давайте разберем ключевые стратегии проектирования компенсаций.
Немедленная компенсация (Immediate Compensation) vs Отложенная компенсация (Deferred Compensation)
На определенном шаге процесса произошла ошибка. Нам нужно откатить изменения, которые уже произошли, здесь у нас есть два варианта.
🔹 Немедленная (Immediate)
Компенсация запускается сразу после ошибки, часто реализуется как синхронные вызовы, особенно когда в системе присутствует Оркестратор.
Когда используется: Используется в системах с критичными требованиями к времени несогласованности данных (например, финансовые операции). В коротких процессах, где пользователь ждет ответа здесь и сейчас. Требуется разблокировать ресурс как можно быстрее (например, бронь места в самолете).
Плюсы: Данные в системе быстро возвращаются в согласованное состояние. Проще отладка и мониторинг процессов. Предсказуемое поведение системы в случае ошибки.
Минусы: Создает дополнительную нагрузку на систему в момент пиковых ошибок. Требуется высокий аптайм всех участников. Если компонент, участвующий в компенсации недоступен, сама компенсация может упасть.
🔹 Отложенная (Deferred)
После ошибки система фиксирует необходимость компенсации. Компенсации ставятся в очередь и выполняются в порядке очередности, по расписанию либо при накоплении определенного числа.
Когда используется: В длительных процессах и при нестабильных внешних интеграциях. Сама компенсация занимает много времени. В системах с высоким требованием устойчивости к внешним сбоям.
Плюсы: Снижает нагрузку на систему и делает ее устойчивее к внешним сбоям. Не блокирует основной поток.
Минусы: Приходится мириться с временной несогласованностью данных. Нужен отдельный мониторинг статуса компенсаций. Пользователь может увидеть временно зависший статус операции.
Частичная компенсация (Partial compensation)
Иногда полная отмена всего процесса и не требуется. В этом случае стоит использовать подход с частичной компенсацией.
Представим такой сценарий:
- Пользователь заказывает в интернет-магазине ноутбук, монитор и мышку.
- Оплата проходит успешно.
- Ноутбук и монитор зарезервированы.
- Возникает ошибка - мышки нет на складе.
Полная компенсация: Отменяем весь заказ, возвращаем все деньги. Пользователь в недоумении, злится или расстроен. Магазин теряет заказ на ноутбук и монитор из-за копеечной мышки.
Частичная компенсация: Система изменяет состав заказа и удаляет мышку. Деньги за мышку возвращаются пользователю. Пользователь заказывает другую мышку.
Такие компенсации требуют усложнения логики. Нужно не только сделать откат, но и пересчитать конечное состояние.
Частичные компенсации полезны, когда:
- Процесс включает несколько независимых сущностей.
- Полный откат будет дороже, чем частичная коррекция.
Влияние на UX - объясняем пользователю, что все пошло не так, как задумывалось
Одна из самых важных стратегий - объяснить пользователю, что произошло, когда все восстановится и какие от него требуются действия.
UX подходы, которые хорошо себя зарекомендовали:
- Понятное состояние процесса, например: "Платеж не прошел, возвращаем деньги, займет до 30 минут".
- Понятные статусы - "Ожидает возврата", "Операция частично выполнена", "Возврат выполнен".
- Асинхронные уведомления о статусе - push, email, sms.
- Не создавать впечатление ошибки - подать как часть нормального процесса, например: "Не удалось зарезервировать товар, производим возврат средств".
- Говорить с пользователем на языке выгоды и действий, а не технических терминов.
Общий вывод
Проектирование компенсации - это всегда поиск баланса между:
- Технической надежностью (выбор стратегии отката)
- Гибкостью (полная или частичная компенсация)
- Пользовательским опытом (прозрачность и понятность)
Лучшая стратегия компенсации - та, которую пользователь не замечает. Но если она необходима, то сделайте ее максимально прозрачной и понятной.
Подпишись на мой канал в telegram
#SoftwareArchitecture #saga #transactions #eventdriven #microservices