Dragonfly v1.21 introduces a new experimental feature: Multi-Tenancy.
Multi-Tenancy: A Game Changer for Data Isolation
Multi-tenancy allows several applications to use the same Dragonfly server without overriding each other's data because of key collisions. For example, let's imagine an online gaming company that develops multiple games. Each game has its own server, operating independently of others. Now, let's also imagine that these games each maintain a leaderboard that needs constant updates and retrievals—a perfect use case for Dragonfly as an in-memory data store.
With multi-tenancy, each game's server can have its own isolated data store.
This allows multiple games to use the same key, such as leaderboard, without any conflicts.
When a game accesses the leaderboard key, it only sees its own leaderboard data, while another game accesses the same key but sees its own separate, unrelated data.
Other Alternatives and Their Limitations
This can, of course, be achieved via other means.
The online gaming company could have instructed each game to use a unique prefix.
The bowling game will only use bowling_game:* keys, while the chess game will use chess_game:* keys.
Alternatively, different games can use different logical databases via the
SELECT command—database #0 for bowling, database #1 for chess, and so on.
Dragonfly without Multi-Tenancy
While these solutions can work, they are not ideal because they require discipline from all developers of all games
and are error-prone to someone accidentally forgetting to use the assigned prefix or to
SELECT the desired logical database.
Introducing Namespaces
As mentioned, Dragonfly simplifies this process with built-in support for namespaces.
A namespace, identified by a string, is a completely isolated data store that can be assigned to Dragonfly users arbitrarily.
Using the gaming company example above, you could create a user bowling_game and assign it to the bowling_ns namespace, while the chess_game user is assigned to chess_ns.
This way, when the bowling_game user authenticates, it will only be able to access its own data.
It cannot read data in the chess_ns namespace even if it tries to, unless it re-authenticates as chess_game.
To further prevent any mix-ups, one can even remove the default user, requiring all users to authenticate before using Dragonfly.
Dragonfly with Multi-Tenancy
To make things even more interesting, namespaces support logical databases.
This means that within each namespace, you can still use the
SELECT command to switch between logical databases,
providing even more granular data management within the same isolated environment.
Moreover, all existing ACL features are fully supported.
For example, we can create another user with fewer permissions, such as bowling_readonly.
This user would be assigned to the same bowling_ns namespace as the bowling_game user, but with read-only access.
Technical Details
Before namespaces, Dragonfly operated with a single data store.
Now, with namespaces, we have a collection of these data stores, each identified by a unique string (like bowling_ns or chess_ns).
When a new connection is established, Dragonfly assigns it to the default namespace, represented by an empty string.
If a Dragonfly user authenticates, Dragonfly updates this client connection to point to the namespace associated with that user.
This ensures all commands executed by that connection are securely isolated within its designated namespace.
Next Steps: Your Feedback Matters
As mentioned, multi-tenancy is currently an experimental feature.
Depending on user feedback and demand, we plan to work more on it and introduce additional capabilities.
For more details, examples, and the latest updates,
check out the namespaces.md file in our GitHub repository.
We'd love to hear your thoughts on this feature. Please let us know if this feature is useful to you or if you'd like to see something added to it by joining our Discord server, following our forum, or signing up for Dragonfly Community. We always want to learn more about how you use our software!
