Cache-aside pattern in Azure - Commands & Configuration

Introduction

Sometimes data is slow to get from a database. The cache-aside pattern helps by storing data in a fast cache only when needed. This way, your app checks the cache first and only goes to the database if the data is missing.

When you want to speed up reading data that does not change often.

When your app reads the same data many times and you want to avoid slow database calls.

When you want to keep your cache updated only when data is requested.

When you want to reduce load on your database during peak times.

When you want to control exactly when data is added or removed from the cache.

Config File - azure_cache_aside_example.json

azure_cache_aside_example.json

{
  "name": "myCache",
  "location": "eastus",
  "properties": {
    "sku": {
      "name": "Standard",
      "family": "C",
      "capacity": 1
    },
    "enableNonSslPort": false
  },
  "type": "Microsoft.Cache/Redis"
}

This JSON file defines an Azure Redis Cache instance named myCache in the East US region.

The sku section sets the cache to Standard tier with a small capacity, suitable for development or small workloads.

The enableNonSslPort is set to false to enforce secure connections.

Commands

This command creates an Azure Redis Cache instance named 'myCache' in the 'myResourceGroup' resource group located in East US. It uses the Standard SKU with a small VM size for caching.

Terminal

az redis create --name myCache --resource-group myResourceGroup --location eastus --sku Standard --vm-size C1

Expected Output

{

  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Cache/Redis/myCache",

  "location": "eastus",

  "name": "myCache",

  "properties": {

    "provisioningState": "Succeeded",

    "redisVersion": "6",

    "sku": {

      "name": "Standard",

      "family": "C",

      "capacity": 1

    }

  },

  "type": "Microsoft.Cache/Redis"

}

→

--name - Sets the name of the Redis Cache instance.

→

--resource-group - Specifies the Azure resource group to contain the cache.

→

--sku - Chooses the pricing tier and features of the cache.

This command retrieves details about the Redis Cache instance to confirm it was created and is ready to use.

Terminal

az redis show --name myCache --resource-group myResourceGroup

Expected Output

{

  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Cache/Redis/myCache",

  "location": "eastus",

  "name": "myCache",

  "properties": {

    "provisioningState": "Succeeded",

    "redisVersion": "6",

    "sku": {

      "name": "Standard",

      "family": "C",

      "capacity": 1

    }

  },

  "type": "Microsoft.Cache/Redis"

}

→

--name - Specifies the Redis Cache instance name.

→

--resource-group - Specifies the resource group of the cache.

This command gets the access keys needed to connect your app to the Redis Cache instance.

Terminal

az redis list-keys --name myCache --resource-group myResourceGroup

Expected Output

{

  "primaryKey": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",

  "secondaryKey": "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY"

}

→

--name - Specifies the Redis Cache instance name.

→

--resource-group - Specifies the resource group of the cache.

Key Concept

If you remember nothing else from this pattern, remember: check the cache first and only go to the database if the data is missing, then update the cache.

Common Mistakes

Not checking the cache before querying the database.

This defeats the purpose of caching and causes unnecessary database load.

Always check the cache first; only query the database if the cache does not have the data.

Not updating the cache after fetching data from the database.

The cache remains empty or stale, so future requests still hit the database.

After getting data from the database, store it in the cache for future fast access.

Not handling cache expiration or invalidation.

Cached data can become outdated, causing your app to use stale information.

Set expiration times or update the cache when data changes to keep it fresh.

Summary

Create an Azure Redis Cache instance to store frequently accessed data.

Use commands to verify the cache is ready and get access keys for your app.

Implement the cache-aside pattern by checking the cache first, then the database, and updating the cache with new data.

Practice

1. What is the main purpose of the cache-aside pattern in Azure applications?

easy

A. To load data into cache only when it is requested

B. To preload all data into cache at application start

C. To automatically update cache without application control

D. To store data only in the database without caching

Solution

1. Step 1: Understand cache-aside pattern behavior

   The cache-aside pattern loads data into cache only when the application requests it and the data is not already cached.

2. Step 2: Compare options with this behavior

   To load data into cache only when it is requested matches this behavior. Options B and C describe other caching strategies, and A ignores caching.

3. Final Answer:

   To load data into cache only when it is requested -> Option A

4. Quick Check:

   Cache-aside loads on demand = D [OK]

Hint: Cache-aside means load cache only when needed [OK]

Common Mistakes:

• Thinking cache preloads all data
• Assuming cache updates automatically
• Confusing cache-aside with write-through caching

2. Which of the following is the correct sequence when using the cache-aside pattern in Azure?

easy

A. Return data -> Check cache -> Read database -> Store in cache

B. Read database -> Store in cache -> Return data -> Check cache

C. Store in cache -> Check cache -> Read database -> Return data

D. Check cache -> If miss, read database -> Store in cache -> Return data

Solution

1. Step 1: Recall cache-aside pattern steps

   The application first checks the cache. If data is missing (cache miss), it reads from the database, stores the data in cache, then returns it.

2. Step 2: Match the sequence with options

   Check cache -> If miss, read database -> Store in cache -> Return data correctly shows this sequence. Other options have steps in wrong order.

3. Final Answer:

   Check cache -> If miss, read database -> Store in cache -> Return data -> Option D

4. Quick Check:

   Cache check first, then DB read if miss = A [OK]

Hint: Cache check first, then DB read if miss [OK]

Common Mistakes:

• Reading database before checking cache
• Storing data in cache before reading database
• Returning data before checking cache

3. Consider this Azure cache-aside pseudocode:

data = cache.get('user123')
if data is None:
    data = database.read('user123')
    cache.set('user123', data)
return data

What happens if the cache contains stale data for 'user123'?

medium

A. The application reads fresh data from the database every time

B. The application returns the stale data without checking the database

C. The cache automatically updates stale data before returning

D. The application throws an error due to stale cache

Solution

1. Step 1: Analyze cache-aside code behavior

   The code returns cached data if present, without verifying freshness. It reads database only if cache miss.

2. Step 2: Understand stale data impact

   If cache has stale data, the application returns it directly, ignoring database updates until cache expires or is invalidated.

3. Final Answer:

   The application returns the stale data without checking the database -> Option B

4. Quick Check:

   Cache returns stale data if present = A [OK]

Hint: Cache returns data if present, even if stale [OK]

Common Mistakes:

• Assuming cache auto-refreshes stale data
• Thinking database is read every time
• Believing stale cache causes errors

4. You implemented cache-aside in Azure but notice your cache never updates after data changes in the database. What is the most likely cause?

medium

A. The application does not invalidate or update cache after database writes

B. The cache service is down and cannot store data

C. The database is not reachable for reads

D. The cache is set to expire data too frequently

Solution

1. Step 1: Understand cache-aside update responsibility

   In cache-aside, the application must update or invalidate cache after database changes to keep cache fresh.

2. Step 2: Identify cause of stale cache

   If cache never updates, likely the app is not managing cache invalidation after writes, causing stale data to persist.

3. Final Answer:

   The application does not invalidate or update cache after database writes -> Option A

4. Quick Check:

   App must update cache after DB changes = C [OK]

Hint: App must update cache after DB changes [OK]

Common Mistakes:

• Blaming cache service downtime without checking app logic
• Assuming database read issues cause stale cache
• Thinking frequent expiry causes no updates

5. You want to optimize an Azure app using cache-aside pattern for user profiles. Which approach best ensures cache consistency when profiles update frequently?

hard

A. Only update cache when the profile is requested next time

B. Set cache expiration to 24 hours and never update manually

C. After updating the database, immediately update or remove the cached profile

D. Preload all profiles into cache at app startup

Solution

1. Step 1: Consider cache consistency needs

   For frequently updated profiles, cache must reflect changes quickly to avoid stale data.

2. Step 2: Evaluate options for freshness

   After updating the database, immediately update or remove the cached profile updates or removes cache immediately after DB update, ensuring fresh data. Only update cache when the profile is requested next time delays update causing stale reads. Set cache expiration to 24 hours and never update manually relies on expiry only, which is slow. Preload all profiles into cache at app startup wastes resources and may cause stale data.

3. Final Answer:

   After updating the database, immediately update or remove the cached profile -> Option C

4. Quick Check:

   Immediate cache update after DB write = B [OK]

Hint: Update cache right after DB changes for freshness [OK]

Common Mistakes:

• Relying only on cache expiration for updates
• Delaying cache update until next read
• Preloading cache wastes memory and risks staleness