Changing the project architecture to a distributed one - where to start?

Question

Software design

Our company decided to switch to a distributed architecture - most of the issues have already been resolved, and now each individual project must be prepared to work distributed, on several servers.
I need to determine where my project might run into problems, and if some things are visible to the naked eye (for example, it is clear that if the login went through node1 and then load-balancer sent a request from the same user to node2, then there will be an error), then to other aspects I don't even know how to approach.
So, the question is - What to read for a more detailed understanding of the consequences of such a transition? Anyway, more specific details and examples of implementation. So far, all I have found are topics in the style of "Choose Spark\Hadoop\Cassandra, set it up, and everything is tip-top". I understand that even that example with a login can be solved with a proper setup (roughly speaking "Bind user to node after login"), but still I want to see what other pitfalls were, and preferably how they dealt with them.
Thank you!

Answer 1

>Bind user to node after login
that the first option is that this one is not really a solution in a distributed architecture.
====
You need to rethink your thinking about how things should work in distributed architectures.
but it's okay, you can start with courses on the courser or look at something in this style
, then you can talk about some specific pitfalls.

Answer 2

Store session data not on a node, but for example in a radish, and everything should theoretically take off. The trash will be in the node update. At the same time, both old versions and new versions should work.