Комментарии 15
INSERT INTO statuses (id, name) VALUES (1, 'PENDING'), (2, 'CREATED');
Для двух статусов табличка, конечно, совершенно необходима.
Почему нет? C точки зрения поддержки целостности тут есть только одна альтернатива, это postgresql enums. Но это ни разу не серебрянная пуля, особенно если список значений надо будет расширять..
Что делать, если не удалось выполнить компенсирующую транзакцию?
Великая тайна сия есть. Но вообще компенсирующая операция должна быть идемпотентной, так что её можно повторять до упора, пока не получится хоть что-то в ответ получить.
угу и за DDOS-ить себя этим "повторным выполнением". @host13 Вам вот [типа этого](https://getakka.net/articles/concepts/supervision.html) надо. В оригинальной Akka тоже эти концепты есть, но в .NET с картинками.
В общем случае там логика, конечно, сложнее простого retry. Вот тут интересно про это написано https://habr.com/ru/company/oleg-bunin/blog/418235/
В ваших примерах обработчик CreateOrderV1 и обработчик события order_created_v1 совершенно не готовы к повторам операций, которые кажется должны случиться когда вы закроете транзакцию, но не сможете отправить сообщение: в базе будут задваиваться и заказы и товары.
со всеми деталями он бы был раза 3 больше
Можете хотя бы словами описать как вы эти проблемы решали? Это достаточно важные детали, чтобы даже этот более простой пример саги, когда можно положиться на надёжный транспорт сообщений, стал более похож на то, что можно реально использовать.
SAGA на golang