Key-Value Stores and In-Memory Caching

A key-value store is a non-relational database that stores data as a collection of key-value pairs. Each record is identified by a unique key, and the value can be a simple string, a complex object (like JSON), or even a binary blob. The key is used for all operations: get, put, delete. There is no schema, no query language beyond key-based operations, and no relationships between records. This simplicity enables extremely high throughput and low latency, often serving millions of read/write operations per second.

Key-value stores are optimized for lookup-heavy workloads. Examples include Amazon DynamoDB, Redis (when used as a persistent store), and Azure Cosmos DB (when configured with the Table API or using the core SQL API with a single partition key). On the DP-900 exam, you need to know that key-value stores are ideal for session management, user profiles, shopping carts, and caching layers.

Internally, key-value stores use a hash table or a distributed hash table (DHT) to map keys to storage locations. When a write occurs, the key is hashed, and the value is stored on the node responsible for that hash range. Reads hash the key and retrieve the value directly. To ensure durability, writes are often replicated to multiple nodes. Some key-value stores (like Redis) offer in-memory storage with optional persistence, while others (like DynamoDB) store data on SSDs.

Key-value stores typically support the following operations:

The performance of a key-value store is measured in operations per second (OPS) and latency (sub-millisecond for in-memory, a few milliseconds for disk-based).

For Azure Cosmos DB Table API (a key-value store):

For Azure Cache for Redis (in-memory key-value store with caching):

For Azure Cache for Redis, you can configure via Azure Portal or CLI. To set maxmemory policy:

az redis update --name MyCache --resource-group MyGroup --set redisConfiguration.maxmemory-policy=allkeys-lru

To verify cache statistics:

az redis show --name MyCache --resource-group MyGroup --query redisConfiguration

For Cosmos DB Table API, set TTL via portal or SDK. Using .NET SDK:

ItemRequestOptions options = new ItemRequestOptions { EnableContentResponseOnWrite = false };
await container.UpsertItemAsync<TableEntity>(entity, new PartitionKey(partitionKey), requestOptions: options);

Key-value stores often serve as the backend for caching layers. For example, Redis can be used as a cache in front of a relational database. The application first checks Redis; if not found, it queries the SQL database and populates Redis. This pattern reduces load on the primary database and improves read latency.

Key-value stores also integrate with content delivery networks (CDNs) to cache static assets, and with message queues (e.g., Azure Service Bus) to store state temporarily.

In-memory caching stores data in the RAM of a dedicated cache server or within the application process. The primary benefit is speed: reading from RAM is orders of magnitude faster than reading from disk or SSD. In-memory caches are commonly used to store results of expensive queries, session data, and frequently accessed configuration.

Azure offers two main caching services:

Additionally, you can implement in-memory caching within an application using IMemoryCache in ASP.NET Core, but this is not a managed service.

When an application requests data, it first checks the cache. If the data is present (cache hit), it returns immediately. If not (cache miss), the application retrieves the data from the original source (database, API, etc.), stores it in the cache with a TTL, and returns it. The cache uses an eviction policy to remove old data when memory is full.

Common eviction policies:

Redis is not just a key-value store; it supports multiple data structures:

Azure Cache for Redis offers three tiers:

Throughput varies by tier and size. For a Standard C1 (1 GB cache), expect ~15,000 requests per second. For Premium P5 (120 GB), up to 1.2 million requests per second.

TTL is critical for cache freshness. Setting TTL too long can serve stale data; too short reduces cache effectiveness. Default TTL is infinite (no expiration), but best practice is to set a TTL based on data volatility. Use EXPIRE command in Redis:

EXPIRE mykey 3600  ; TTL in seconds

Key-value stores differ from relational databases (no schema, no joins, no ACID beyond single record) and document databases (documents have structure, can be queried on fields). On the exam, remember that key-value stores are optimized for simple lookups at scale.

In-memory caching is distinct from content delivery networks (CDNs) which cache static content at edge locations, and from application-level caching (e.g., IMemoryCache) which is local to a single server.

A large e-commerce platform uses Azure Cache for Redis to store shopping cart data. Each user's cart is stored as a Redis hash with fields like item ID, quantity, and price. The cart is keyed by a session ID. This approach allows sub-millisecond reads and writes, essential for a smooth user experience. The cache is configured with a TTL of 24 hours to clean up abandoned carts. The application uses cache-aside pattern: on add/remove, it updates both Redis and the underlying SQL database for durability. During peak traffic (Black Friday), the cache handles millions of operations per second. Misconfiguration, such as setting TTL too low (e.g., 5 minutes), caused users to lose carts frequently, leading to support tickets. The fix was to increase TTL and implement a background job to persist active carts to SQL.

An online game uses Redis sorted sets to maintain a global leaderboard. Each player's score is stored as a member with a score. Redis provides O(log N) operations for adding scores and O(1) for retrieving top players using ZREVRANGE. The leaderboard is updated in real-time as players finish games. The cache is deployed in a Premium tier with clustering to handle 500,000 concurrent players. Persistence (AOF) is enabled to avoid losing leaderboard data on restart. A common issue was using a single Redis instance without clustering, causing CPU saturation at 100% during peak. After sharding across 10 shards, throughput scaled linearly. The exam may ask about using sorted sets for leaderboards—remember that Redis is the go-to solution.

A SaaS provider uses Azure Cache for Redis as a distributed session store for its ASP.NET Core web app. Session data (user login, preferences) is stored in Redis using the built-in AddDistributedRedisCache extension. This allows any web server in a load-balanced pool to access the same session data. The cache is configured with a TTL of 20 minutes for session timeout. The standard tier with replication ensures high availability. A common mistake is not setting a TTL, causing sessions to accumulate indefinitely, leading to out-of-memory errors. Proper monitoring with Azure Metrics (e.g., cache misses, evictions) is essential. The exam may ask about session state vs. cache—know that session state is a specific use case of caching.