-2

I am breaking down a stateless microservice into multiple ones. I would like to maintain statelessness in all of them. Some requests require data provided by one (or more) of the other services. The choreography-based Saga Pattern solves this by letting services communicate through event streams and storing the original request in a pending state until the requested data is delivered back. Unfortunately storing the pending request in memory makes the services that rely on others stateful. I know this is not the end of the world but it makes things more complicated and I would like to avoid that if possible.

I can think of two alternatives that would allow all services to be stateless:

Storing the pending requests in some database temporarily

I'm not a big fan of this idea because it will probably slow things down quite a bit and requires additional infrastructure that needs to be maintained and is a potential point of failure.

Attach pending request data to event and push response to client

I use Nchan to send real-time updates to clients. I could attach all required data (everything needed to complete the request) to the event generated by Service A and send it off to Service B without storing the pending request in memory. Then Service B would do its thing and once it is done it could either directly send the response (of the original request) through Nchan or send an event back to Service A which would then send the response via Nchan.

Option 2 seems most viable to me right now. What do you think and is there another option I am missing?

2um9YJ6haZ7wKP4m
  • 79
  • 8

1 Answers1

0

Saga Pattern is used to ensure that in case of failure all already executed updates are compensated. Stateless service by definition doesn't store data, so it really cannot support updates. So your question in its original form doesn't make sense.

Maxim Fateev
  • 6,458
  • 3
  • 20
  • 35
  • I am new to this pattern but it is my understanding that it provides ["a mechanism to implement transactions that span services"](https://microservices.io/patterns/data/saga.html). For failed write transactions compensating may be necessary, not for reads though. I am aware that this requires storing pending transactions somewhere. What I am asking is if there is some common solution for storing information like this anywhere but within the microservice itself. A fast key-value store seems like it could work for instance. That way the microservices can stay stateless. – 2um9YJ6haZ7wKP4m Mar 02 '21 at 13:22
  • Look at temporal.io that supports orchestrating microservices in the presence of various failures. Here is the SAGA example: https://github.com/temporalio/samples-java/blob/master/src/main/java/io/temporal/samples/bookingsaga/TripBookingWorkflowImpl.java – Maxim Fateev Mar 02 '21 at 19:36