Please note that even with client APIs (Java, Node.js), this is not always obvious or explicit at the language API level, which can cause a session to be created. There will definitely be an explicit transaction creation with multiple statements, but other operations can also do this. If you use the same connection for the user interface (browser) and API (REST or XCC), then the browser application will probably do what creates the session state.
The safest, but least flexible configuration is TCP Session Affinity. If supported, they will fix most of the problems associated with load balancing. Cookie Session Affinity relies on guarenteeing that the load balancer uses the correct cookie. Not all code is equal. I have had cases where load balancing did not always use a cookie. Changing the configuration to “Load Balancer provided that Cookie Affinity” is fixed.
None of this is required if all of your messages have no status at the TCP level, HTTP level, and application level. A later version cannot be output by the server. Another reason is that your application or middle tier, together with other applications or with the same application, connects to the same load balancer and port. It can be difficult to make sure that there are no “crossed wires”. When ML receives the request, it associates its identity with the client's IP address and port. Even without a load balancer, most modern HTTP and TCP client libraries implement socket caching. A great win in perfumery, but a hidden source of subtle random serious errors if the library or application shares cookies (not uncomnon). The TCP cache and Cookie Jar used by different application contexts can ultimately send state information from one unrelated application to the same process in another. Basically, these are mid-level application servers that can simply transfer requests from the first level without domain knowledge, believing that, based on the low-level TCP libraries, "do the right thing" ... They do the right thing - to use the preface, which they had in mind library programmers - do not assume that your case is one that the authors of the library suggested. Symptoms are usually very rare, but catastrophic problems with transaction failures and, possibly, data corruption and security problems (at the application level), because the server cannot distinguish 2 connections from the same average level.
Sometimes the best strategy is to balance the balance between the first tier and the middle tier and direct connection from the middle tier to MarkLogic. Especially if caching is done on a load balancer. Most often, caching can be useful between the middle tier and the client, and then the middle tier and the server. It is also more like the classic three-tier architecture used with RDBMS .. where load balancing between client and business logic layers is not between business logic and the database.