thanks for sharing your thoughts, you have the architecture right, kividb uses shared everything with fine-grained locks, similar to keydb and garrnet. it uses 8 shards per core, each with a hash map behind an rwlock, with separate locks for collection values. we lock all relevant shards in a fixed order. Multi and Exec and arbitrary-key scripts run behind a server-wide exclusive gate, so the transaction-heavy workloads serialize and also lua scripts with shared hash tags can run in parallel, which works well for use cases like bullmq. and for snapshots, we are avoiding forks and copy-on-write memory spikes by capturing immutable string references but the tradeoff is a write pause that grows with key count, which is not an issue with dargonfly for it's non-blocking snapshotting. Please do try this design with dragonfly as it is also a replacement to memcache which kividb isn't yet, haha