Hopefully by redundancies, you dont mean sharing data access logic
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)
... which perhaps just shifts the question to "why do you need multiple independent teams and not just use a monolithic development team?"
POST /lock
This is only a slight exaggeration over some of the stuff I've seen people try to pull.