Data Structures and Application Patterns

With MemoryDB's durability, Multi-AZ resilience, and backup/restore mechanics established in the previous lesson, you can trust that data written to this service survives failures and restarts without external persistence layers. That trust unlocks a more consequential question: what can you actually build on top of a durable, sub-millisecond data store? MemoryDB exposes the full Valkey/Redis OSS-compatible API, which means every native data structure (strings, hashes, lists, sets, sorted sets, and streams) is available as a fully supported building block for application design, not merely as a caching primitive. This lesson maps each data structure to concrete, low-latency application patterns and explains why a durable in-memory primary database changes architectural decisions that previously required pairing a transient cache with a separate persistent store. Mastering these patterns is also the prerequisite for the next lesson, where vector search indexes and AI-era retrieval pipelines build directly on the same engine.

Core data structures explained

MemoryDB inherits the rich data-structure vocabulary of the Valkey/Redis OSS ecosystem. Each structure occupies memory for sub-millisecond access, yet every mutation is durably persisted through MemoryDB's Multi-AZ transactional log. Understanding what each structure does, and what it costs in terms of memory and scaling behavior, is the foundation for every pattern discussed later.

The following structures form the building blocks of nearly every real-time application pattern on MemoryDB.

• Strings: The simplest key-value unit, supporting atomic INCR and DECR for counters, GET and SET for flags or serialized objects, and TTL for ephemeral records that expire automatically.

• Hashes: Compact multi-field objects stored under a single key, ideal for user profiles, session-like state, or configuration blobs where individual fields can be read or written independently without deserializing the entire object.

• Lists: Ordered collections supporting push and pop from both ends, useful for simple queues, recent-activity feeds, or bounded logs that are trimmed with LTRIM to cap memory.

• Sets: Unordered collections of unique members, enabling tagging, membership checks with SISMEMBER, and intersection or union operations across multiple sets.

• Sorted sets: Each member carries a numeric score, enabling ranked retrieval in $\mathcal{O}(\log N)$ ...