You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
There seems to be a lot of complexity in Soketi related to doing Replicaiton - you have various mechanisms like Cluster, PM2, Redis etc... and documentation about when to use which one. It seems the source of this complexity is that Redis is only single threaded - I presume this is the reason that it is recommended to scale out horizontally rather than vertically.
Describe the solution you'd like
Cluster and Redis could be merged into one mechanism if DragonflyDB or KeyDB are used instead of Redis. They are multithreaded Redis drop-in replacements, which would automatically give considerably more performance with a single instance. So, implementing either would solve whatever problem is being addressed by the PR to remove Cluster #705.
KeyDB is owned/backed by Snapchat, while Dragonfly seems to have VC backing of some sort.
KeyDB has active-active/multi-master replication, which would be ideal. However, its development pace seems to have slowed down a lot and they have not been good with communication - particularly with regards to addressing major and persisting bugs.
Conversely, DragonflyDB is very actively developed and the team is very communicative. Replication would be more cumbersome than KeyDB, as it uses a standard Active-Replica mechanism. But that's the same is standard Redis, and can be alleviated by using Redis Sentinel which is already built-into Soketi, to better manage the replication, leader election with automatic failovers.
Or, given that they're both drop-in replacements for Redis, maybe either could be used through some configuration setting.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
There seems to be a lot of complexity in Soketi related to doing Replicaiton - you have various mechanisms like Cluster, PM2, Redis etc... and documentation about when to use which one. It seems the source of this complexity is that Redis is only single threaded - I presume this is the reason that it is recommended to scale out horizontally rather than vertically.
Describe the solution you'd like
Cluster and Redis could be merged into one mechanism if DragonflyDB or KeyDB are used instead of Redis. They are multithreaded Redis drop-in replacements, which would automatically give considerably more performance with a single instance. So, implementing either would solve whatever problem is being addressed by the PR to remove Cluster #705.
KeyDB is owned/backed by Snapchat, while Dragonfly seems to have VC backing of some sort.
KeyDB has active-active/multi-master replication, which would be ideal. However, its development pace seems to have slowed down a lot and they have not been good with communication - particularly with regards to addressing major and persisting bugs.
Conversely, DragonflyDB is very actively developed and the team is very communicative. Replication would be more cumbersome than KeyDB, as it uses a standard Active-Replica mechanism. But that's the same is standard Redis, and can be alleviated by using Redis Sentinel which is already built-into Soketi, to better manage the replication, leader election with automatic failovers.
Or, given that they're both drop-in replacements for Redis, maybe either could be used through some configuration setting.
The text was updated successfully, but these errors were encountered: