I have a HA scheme of N nodes, each on a different AZ and I'm planning to implement services which are loadbalanced and scalable in the event of bursts of activity.

For static services such as web servers this works fine, it's easy to scale up since the files served (the state) is the same for all of them. But when it comes to dynamic state it gets more complicated.

Let's we have a service A which has several instances. Queries towards the service are load balanced to some random instance and the queries may be CRUD. In the diagram below, S-B = Service B, S-A = Service A (and instance number)

State owning design of Service A (S-A)

1. What is the best practices to guarantee that the state is synced between all instances of service A? The goal is to have the multi-instance nature of service A to be completely transparent to a client of service A, and still allow service A to scale seamlessly.

So far I've encountered a few approaches:

  1. Message broker which keeps the latest state in-memory and allows the instances to publish and subscribe changes to the state
  2. Database driven approach where no state is held in the instances, and every potential operation within service A which has to do with state has to be queried to/from the database
  3. Some sort of raft-algorithm based approach

All of these have downsides in their own right and I'm not sure which one to aim for. I'm also not sure if my initial approach to "pod" the state owning services up is correct either. 2. Is it better to keep a fixed amount of instances and then scale up the hardware of said instances?

New contributor
baal_imago is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

baal_imago is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.