Consider a microservice architecture composed of a number of asynchronously communicating workers. Each worker deals with an isolated task and may have its own specialized database. Now consider that the services are meant to work on a common task by starting to do their specific computation and, once finished, contribute to the final goal by publishing their result.

As an example, I sketched this (made-up) situation (This sketch is very poor, please see a corrected version below):

Example of microservices with shared state

A car dealership requests a car model XY at time T with given properties (say color, engine type, etc.). Once requested, the isolated services start to work on their part: the chassis factory fabricates the chassis in the correct color and sends it to the assembler, etc. A car assembler service waits for the individual parts and always assembles them as soon as they arrive. Once completed this service sends the final product to the requesting service.


  1. Is this a valid domain for a microservice architecture?
  2. How can the services share the required information in a safe way? E.g. the "cars currently in production"?
  3. Which communication technology would be the optimum choice? Esp. to avoid usage of too many different technologies.

Some additional thoughts:

  • The car dealership is meant to be the single source of truth about which cars are currently in production. Optimum would potentially be a "flag" that is raised and visible for all services until the production is done. ---> This sounds like a shared variable, e.g. using Redis.
  • The car part producers have to communicate with the car assembler. In the actual application there is more communication to be done --- imagine the part factories inform the car assembler now and then about their state in form of events. So this is better suited for e.g. AMQP or Kafka!?

All shared ideas and experiences are appreciated!


Something I got really wrong with the "car" analogy was that the subtasks are finite. In my actual application, the subtasks will rather run until the "Car dealership" indicates that the overall task is done.

Please consider the more abstract but more accurate sketch here: enter image description here

Now imagine that Only the task manager knows when tasks start and when they are finished. This information has to be communicated to all the other services and retain eventual consistency between them.

  • 1
    "The car dealership is meant to be the single source of truth about which cars are currently in production" -- That seems odd; car dealerships are usually a sales function; I wouldn't typically expect it to be the authority for scheduling of production-line manufacturing, however the business model above seems to be missing a 'command-and-control' function to orchestrate and schedule the use/allocation/timing of jobs and resources -- Production lines generally aren't composed of autonomous units; I would usually expect decision-making to be separate from the work itself. Commented Aug 2, 2022 at 7:13
  • It seems because I made up a largely invalid example I guess :D I am struggling to find a good analog for my actual use case. The point I wanted to make was that there is one service that indicates to all other services that they should be working on task XY at the moment. This service needs to be sure that the other services are really doing their job in case they are alive (assume there are heartbeat mechanisms taking care of this separately). Commented Aug 2, 2022 at 7:39
  • The big problem with my example is that the processes I used are finite, while in the actual use case the services would work on their sub-task indefinitely until the "car dealership" indicates that the overall task is finished. Commented Aug 2, 2022 at 7:40
  • @BenCottrell Please see my edit, I hope it makes more sense now. Commented Aug 2, 2022 at 8:18
  • your problem is unclear. everything just works assuming the task manager requests parts from the various microservices?
    – Ewan
    Commented Aug 2, 2022 at 9:34

1 Answer 1


Microservices should only be small enough to do one useful function from a domain perspective. If you have a generally unknowable amount of services being called, that is a massive red flag that things are way to micro. If you need a significant amount of services, then staying stateless is a good option, send everything needed in and pass the result along to the next, task manager can handle the orchestration. If you really need to manage state between all the services then the task manager has to do it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.