Don't use static variables and shared state in service code and you won't have race conditions. Use rpc, cqrs or a number of other service oriented approaches.

Don't use static variables and shared state in service code and you won't have race conditions. Use rpc, cqrs or a number of other service oriented approaches. Go, as an example tends to embrace an approach that scales well and doesn't have the issues you mention. Of course properly using mutexes and locking can help, so can serially shared state where state is mutated by a single process with request/response. Or you can use something like Nude, where there's only a single language execution thread. Most can leverage an RDBMS as the source of truth for state. Tighter coupling doesn't mean ignoring ways to reduce certain risks and complexity. A more monolithic code base doesn't have to be muddy. As to the smaller services, what happens when you have literally hundreds of smaller services to orchestrate? Is that really reasonable for an application that will never have even a million users? It comes down to balance and simplicity over complexity. Micro services don't remove complexity, they only shift it. And if the same people are responsible it becomes more to try to reason with.