Clarification on Redis Cluster transactions and client-side support

[eye-dee]

Description:
I came across this detailed explanation on StackOverflow regarding transactions in Redis Cluster:
https://stackoverflow.com/questions/42088324/is-there-any-redis-client-java-prefered-which-supports-transactions-on-redis-c/42091605#42091605

The conclusion there was that:

• Transactions are safe if all keys are on the same node.
• Cross-slot transactions require trade-offs and are not natively supported.
• Clients have not agreed on a global strategy.

---

Questions:

• Is this explanation still relevant today for Redis Cluster transactions (as of Redis 7 / current client libraries)?

• If so, would it make sense to introduce a clear API to obtain a connection directly by node id or by slot in order to:

  • Safely manage single-node transactions.
  • Make it more explicit to the developer which node they’re interacting with.

---

[mp911de]

We don't plan adding transaction support for Redis Cluster. As you already mentioned, knowing the slot and pin the transaction to a specific node could make this work, but we would have to know the slot and ideally run some verifications for keys that do not reside on the same slot. These are quite significant efforts for under-the-hood connection routing.

In our infrastructure, we allocate the connection first before we even handle the first command with a key, so I don't really see a path forward here.

Another aspect is that Redis can be used in various setups (Standalone, Master/Replica, Sentinel, Cluster). Each of these modes leaks in some sense into our abstractions and that is not a proper design. We don't want to fix more of Redis' flaws.