Singleton client needlessly sharing session token: wasteful?

[Timo van Zijll Langhout (Timovzl)]

I'm confused about handling session tokens efficiently when using Session consistency.

Consider an application handling many API requests. Let's say that there may be scenarios where an API request handler needs to read its own writes, which session consistency supports. API requests are independent of one another. The API requests would be a good candidate for the session boundary.

In general terms, the documentation strongly encourages the use of a singleton CosmosDB client application-wide. It also states that the client automatically tracks session tokens.

Doesn't the singleton client needlessly share the session tokens between unrelated processes, thus reducing concurrency?

Once we have many requests and many partitions, a benefit of session consistency is that requests can interact with different physical partitions without waiting for replication of one another's data. But with the recommended practices, the session token is shared (per application replica), and reads for request B will wait for data replication of the writes of unrelated request A. Does this not wastefully reduce concurrency?

If my understanding is correct, then what is the way to go for my scenario? I presume I would need to manage session tokens myself. This leads to the following questions:

• Are there consequences to also providing the session token on writes? (Making the distinction between reads and writes would take extra development effort.)
• How are session tokens used correctly across partitions? Ex. Write to partition A, obtaining session token A. Write to partition B, obtaining session token B. Read from all partitions, passing session token B. Can I guarantee reading my own writes, even from partition A? (And if yes, how exactly does partition A guarantee this, when I'm passing a token without correlation to any writes on that partition?)