0

I have two instances of a spring boot microservice (Microservice A) and a load balancer. The Spring boot application is running in AWS Fargate with 2 desired tasks (2 instances of Microservice A).

If I request the microservice A the load balancer leads me at the first request to microservice A instance 1. The next request will be load balanced to microservice A instance 2. This is alternating on every future request.

On microservice A I have a Spring Service that has a List<String> attribute. On every request I put something in this List. The List is hold in memory, I dont want to put this List into a database. In my case every further request fills the list on microservice A instance 1 and microservice A instance 2 alternating. But I want to fill only one List with every future request so my List input is not spreaded across my microservice instances.

So my question is:

Is there any way to share one List between these two microservice instances?

Do I have to establish some kind of communication between them or is there a better solution for this? Or do I have to configure my load balancer? A solution would be storing it in a database. But this would produce many DB calls and I want to prevent this because the purpose of the code is to prevent DB calls.

anvin
  • 450
  • 2
  • 8
  • 22

2 Answers2

1

For your goal, using an external service (Redis | DynamoDB | ....) is a common pattern. If you don't want to use a DB (or making API calls anyway) the other thing I can think of is to use a shared file system (EFS) to keep this state. See here for more info, especially the use cases towards the end of the blog. Instead of storing the list in memory you'd flush it on the file system (which happens to be shared among the tasks). Separate tasks in the same service have no other way to communicate among them. I don't know the exact requirements you have (concurrency, latency, etc) but using DynamoDB seems to be the best way forward. Very low latency, 0 burden to "manage a database".

mreferre
  • 5,464
  • 3
  • 22
  • 29
0

I generally like the approach of @mreferre.

You might take a look into AWS Sticky Sessions. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html

However be warned: If the sticky target of an user is going down, you need to make sure that the user is not constantly sent to the now-down target. You need to carefully consider if sticky sessions match your usecase. Maybe you can work with a short duration cookie to minimize duration of bad sticky connections.

kurr kurr uma ma
  • 31
  • 3