0

I'm looking for architectural guidance.

I've got this monolithic application. It has a payment platform functionality, where payments are made, scheduled or on demand, via some banking API.

Payments used to be stored in DB, along with all relevant info like banking transactions, etc. Making the payment is inherently unstable error-prone process, where many bad things can happen like unexpected remote API outage, and code quickly becomes unmaintainable with all these try-catches and conditions. Additionally, I want the payment process to continue from where it failed.

So I decided to switch to event-driven microservice architecture, where I would present the payment process as Saga(state machine). Sagas are implemented as subclasses of given abstract class in framework of my choice, and it has its state.

Now I can logically split the payment process into multiple states, transitioning from one state to another upon arrival of event signifying that certain payment step had finished.

It all sounded logical until I started prototyping it and stumbled upon this question: do I move the payment records entirely to Saga state, or only put the data required for Saga execution, and leave all other fields in original DB table? If I leave all the data in original DB table I will need to fetch/update this data from Saga handlers, and I realize I could do all the same by handling corresponding events by separate handlers without Sagas at all. What benefits does Saga offer then? Orchestrating events manually without any Saga helper class still implements the Saga pattern, right?

Any good example code/articles would be great, because I only managed to find the code where the whole business entity was converted to Saga state.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
kosmakoff
  • 109
  • 1
  • Saga is mostly used in microservices architectures to make distributed transactions but when you have all your data in one database you only need a state machine. So why do you want to use the saga pattern? – Darem Jun 18 '21 at 10:19
  • What are your bottlenecks that warrant microservices? Has your monolith reached a dead-end in terms of performance scaling or organisational friction? If neither, you probably want to follow the rule #1 of microservices: you don't need microservices. I mean, we could still help you with Saga design, but the microservices part seems irrelevant and distracting. It also could be useful to know if you're using Event Sourcing. – Shadows In Rain Jun 18 '21 at 11:35
  • see [Why do 'some examples' and 'list of things' questions get closed?](https://softwareengineering.meta.stackexchange.com/a/7538/31260) – gnat Jun 18 '21 at 11:55
  • Monolithic? As in has been runnning in production for years? If yes, you might need to have others approve this rewrite. – Thorbjørn Ravn Andersen Jun 18 '21 at 15:43

0 Answers0