Redis is a Cache Server that stores key and value pairs.

The Key is a string Value is of data with predefined Redis Datatypes.

This tutorial covers a naming convention for designing key names of a Redis database.

Redis Keys Standard Naming Conventions.

Following Standard naming conventions are used for designing keys

Key size: When we were given plain strings, it is difficult to understand and maintainability.

Also, If the key size is more, Memory consumption is more, which results in slow searching keys lookup for comparison.

Key Schema: Due to all this, It is good to have a key with schema structure to have a better understanding Let’s consider, You want to store users’ security objects in memory.

How do you design the schema for keys?

Let’s see what the user’s security object hierarchy looks like.

Users contain a list of users, each user contains roles, permissions, and groups.

user:1
user:1:roles
user:1:groups
user:1:permissions

user:1
user:john:roles
user:john:groups
user:john:permissions

As you see, Each key contains separator : for naming convention and follows Object:id:subobjects syntax.

With these naming conventions, It helps developers

  • Understand the keys in clear and readable form
  • Maintainable and easy grow the schema
  • also, Querying keys in the simple form. For example, Get all queries that start with user:

Namespace:

Redis server stores keys to all applications.

Always prefer to use namespace for each application.

For example, You are designing tenant users’ security applications, It is better to have a schema like

tenant:object:data:subobject

Here are namespace key examples

tenant1:user:1
tenant1:user:1:roles
tenant1:user:1:groups
tenant1:user:1:permissions

tenant2:user:1
tenant2:user:1:roles
tenant2:user:1:groups
tenant2:user:1:permissions

In this, data is grouped by namespace and easily readable and maintainable

Redis keys Standard Naming Conventions rules

  • Keys are binary-safe. Any valid string including an empty string is a valid key
  • Key allowed maximum size is 512MB
  • Large size keys are not recommended due to slow performance in search and lookup cost involved.
  • Also, Short keys are not recommended such as e11r, Instead, employee:11:roles is more readable.
  • Design a schema for easy to understand by others
  • Grouping the parts of objects with data using a separator is a good idea for naming keys.
  • Also, if you are working on multiple applications, you can use namespaces for each application to differentiate between applications