Loading page
About this tool
Design a namespaced Redis key convention with environment, tenant and version segments plus cluster hash tags.
This builder designs a namespaced Redis key convention — app:env:tenant:entity:id:attribute — following the object-type:id scheme recommended in the Redis documentation, with colon separators, optional schema-version segments and Redis Cluster hash tags. Every segment is validated against practical key hygiene: no whitespace or control characters, no separator collisions, no stray braces, case-consistency, and a length check against a 128-character team guideline (Redis itself allows up to 512 MB). It is for teams standardising cache and session keys before ad-hoc names spread through the codebase.
Open Redis Key Naming Builder on AltFTool — it loads instantly in your browser.
Provide your input — an image, text, or data.
Let the tool analyze or generate the result.
Review, refine, and reuse the output wherever you need it.
Produces both a template with placeholders and a worked example you can paste into a style guide.
Hash tags are placed on the tenant or the entity+id pair, with a warning about hot-spotting a single slot.
Whitespace, separator collisions, braces, mixed case and over-long keys are caught before they ship.
The Redis documentation recommends colon-separated object-type:id schemes such as user:1000 or user:1000:followers, keeping keys short but readable. Most teams prepend an application namespace and environment (shop:prod:user:1000) so multiple apps can safely share one Redis instance.
Up to 512 MB — Redis keys are binary-safe strings. In practice the docs advise against long keys because every lookup pays for the key's memory and comparison cost; a common team guideline is to stay under roughly 128 characters, which this tool checks against.
In Redis Cluster, the hash slot is computed from the substring between the first { and the next } in the key — the hash tag. Keys sharing a tag, like {acme}:cart:1 and {acme}:cart:2, map to the same slot, which is required for multi-key commands such as MGET, SUNION or MULTI transactions across those keys. On a single non-clustered Redis instance hash tags change nothing.
Yes — user:1000 and User:1000 are two different keys. That is why this builder warns on mixed-case segments: an all-lower-case convention removes an entire class of cache-miss bugs caused by inconsistent casing between services.