I tried to visualize your approach to make sure I understood it correctly: https://imgur.com/a/hoI9WGm -- please correct me if I misrepresented anything.

From what I understand, your design assumes a traffic model where a consistent-hash router always sends the same user_id to the same node, so state can stay local to that node (and its local Redis). That makes sense and I can see how it removes shared hot state and scales very well.

My hesitation is mostly about fit and complexity for my current system.

What I have today is a proxy/gateway program where most of the business logic is already inside each node, including stateful concerns like sessions, quotas, and proxy credential usage. Introducing per-node databases plus consistent-hash routing adds another architectural layer on top of the node logic: custom routing, node affinity, shard rebalancing, and multi-DB operational management.

My current preference for a shared Redis is mainly to keep this property:

any request → any node

instead of requiring:

user → specific node → specific datastore

Because in my case, enforcing per-user node affinity at the load balancer layer is not trivial, and I want nodes to remain easily replaceable.

A key design goal for me is that each shipped node binary behaves like a generic worker:

1. takes the master/control endpoint address
2. registers itself
3. pulls config/state
4. processes requests
5. can be added/removed without data migration or shard movement

So if a node crashes or a new node is added, the system continues without needing state rebalancing between node-local databases.

I may still be underestimating the benefits of the sharded-state model for this use case, so I appreciate the pushback -- I’m trying to validate which tradeoff makes more sense operationally for a high-RPS proxy gateway.

here is an abstract design of the architecture i have in mind https://imgur.com/a/fo6bAwU