Redis / Basic: keys and bounded data structures / Lesson 1

Redis servers, clients, keys and types

Locate an operation inside Redis and choose a key/type contract before storing values. Separate process memory, client behavior, namespaces and persistence guarantees.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain key identity, data types and client protocol boundaries.
Distinguish a Redis instance from its durability and availability design.

A fast data structure server still has contracts

Redis serves commands over a client protocol and holds working data structures in memory. A client library serializes arguments, manages connections and interprets responses; it is not the storage engine. Keys identify values whose Redis type determines which commands apply. Persistence, replication and failover are additional designs, not consequences of receiving a successful SET reply. A cache entry, a session record and a durable work queue can therefore use the same technology with very different loss and recovery requirements. State the business purpose before treating every key as disposable.

Read a synthetic command contract

These commands describe a previously empty disposable training namespace. SET stores a string, GET reads it and TYPE identifies its Redis type. Colons are an application naming convention, not hierarchical storage or an access-control boundary by themselves. No server is contacted and no command is executed by the course. Expected replies are reasoned from the declared fixture, with client formatting omitted. Use names that express application, tenant and object purpose while avoiding personal information or secrets that could appear in diagnostics and operational tooling.

redis Illustrative Redis commands for an empty lab namespace

SET lab:portal:label "Training portal"
GET lab:portal:label
TYPE lab:portal:label

Expected output

OK
Training portal
string

Expected replies are OK, the string Training portal, and string. This says nothing about disk persistence or another server.

Choose the value shape and serializer deliberately

Core types include strings, hashes, lists, sets, sorted sets and streams. A Redis string can contain arbitrary bytes; JSON text stored in one is still a string rather than automatically indexed document fields. Client decoding can turn bytes into text, but must use an agreed encoding. A key cannot simultaneously be a string and a hash. Define the value type, serializer, owner, expiry and compatibility version in the application contract. An identifier written in a key name is not a substitute for checking the request’s tenant and operation authority.

Model naming without pretending to run Redis

The Python function constructs deterministic keys from validated synthetic components. It rejects a delimiter that would make two logical components ambiguous under this local convention. This is application logic only: it does not establish Redis ACLs, prevent every unsafe name or reserve a key. Real systems may require opaque identifiers, length limits and escaping conventions appropriate to their data. Keep key generation in one reviewed module so readers, writers, invalidators and migration jobs agree on identity. A naming change can otherwise create a silent second cache population.

python Offline key-construction example

def cache_key(tenant, record_id):
    if not tenant or ':' in tenant or ':' in record_id:
        raise ValueError('INVALID_KEY_COMPONENT')
    return f'lab:{tenant}:record:{record_id}:v1'

assert cache_key('training-a', '17') == 'lab:training-a:record:17:v1'

The assertion checks one local naming rule. It opens no socket, creates no Redis data and proves no access-control property.

Record the exact product and topology

Redis Open Source, Redis Software and Redis Cloud have different release policies, operating surfaces and available capabilities. A managed endpoint can restrict commands or hide topology behind a service interface. Do not copy self-managed administration instructions into a managed deployment or assume a release number names the same feature bundle everywhere. This course uses an explicitly stated Redis Open Source baseline and ordinary core commands, with newer features labeled. Check official version support and client compatibility before independent practice. All live commands remain non-runnable illustrations; offline calculations do not certify service behavior.

Common errors and fixes

WRONGTYPE Operation against a key holding the wrong kind of value

Why it happens: The command does not match the key’s stored Redis type.
How to fix it: Inspect the intended key/type contract and correct the caller rather than deleting arbitrary data.
Prevent it next time: Centralize naming and type ownership for every key family.

A successful write is called a durable backup

Why it happens: Command acknowledgment was confused with persistence and independent recovery.
How to fix it: Review persistence, replication and restore evidence separately.
Prevent it next time: Document the loss budget for each key’s business purpose.

Two applications overwrite the same key

Why it happens: Their key namespaces or serializers were not coordinated.
How to fix it: Identify ownership and migrate through a reviewed compatible naming policy.
Prevent it next time: Test key construction across all producers and consumers.

Check your understanding

1. Does the name lab:tenant-a:record:17 itself prevent tenant B from reading it?

Show worked solution

No. It expresses identity under a naming convention. The application and appropriate Redis access policy must enforce which identities can perform which operations. Keep tenant scope in request handling and review key-pattern permissions where supported. Naming improves coordination but does not create authorization merely by including a tenant label.

2. A team stores JSON in a Redis string. Does that make nested properties independently queryable by core GET?