So, normally, you do not need to lock. If all your services are single threaded, and you have a good transactional model, you only need to duplicate services to

So, normally, you do not need to lock. If all your services are single threaded, and you have a good transactional model, you only need to duplicate services to create parallel routes. You need to lock when you write a shared area from multiple sources with no opinion on write ordering. But say your pipeline is client-> decorator -> processor -> observer with client publication -> external partner, each input will go into a set of instances different from the previous and next one, and rejoin at the output who will queue and order them. You have parallel heavy work and sequential light result publication. Your simple output must be as fast as the sum of your parallel routes to minimize queueing. Ofc it s more complex, and I prefer 0 network hop myself, but I work on a large investment bank micro service system and we do not lock, and the component are both simple and complex enough that when one disappear, everything else waits or rebalances, and when it reappears it can catch up automatically, and go on. It consumes large amount of memory to keep a duplicated state in each component and persistence is not guaranteed to be on time (in fact, our persistence layer was 30 minutes behind by mid day, for years, until we dug into the 30yo sql)