How to share state between microservices

Question

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):

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.

Questions:

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!

---

Edit

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:

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.

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.