From 500ms to 5ms: The .NET Redis Caching Guide That Actually Works

Your API is fast. In development, anyway.

Then production happens. Real users. Real traffic. Thousands of requests hammering your database every second. Suddenly that "fast" endpoint takes 500ms. Then 800ms. Your SQL Server is gasping for air, and you're staring at a dashboard that looks like a heart attack in slow motion.

I've watched this movie before, usually starring me, frantically scrolling through logs, wondering why the tests lied.

Here's the thing: most performance problems aren't code problems. They're caching problems. You're asking your database the same questions a thousand times when you could ask once and remember the answer.

Redis changed everything for me. Not because it's magic (it's not), but because it's stupidly fast, we're talking sub-millisecond fast and once you understand a few key patterns, those 500ms endpoints drop to 5ms.

After implementing Redis caching across dozens of .NET projects, I've seen the same mistakes, the same "why didn't anyone tell me this?" moments, over and over.

This is the guide I wish someone handed me on day one.

---

TL;DR#

If you're short on time, here's what you need to know:

The payoff: 30x faster responses, 95% less database load, happier users.

Now, let's build it step by step.

---

1. Install and Set Up Redis#

Before we can cache anything, we need Redis running. The good news? This takes about 2 minutes.

You have two options: Docker (recommended) or native installation. Choose what works best for your environment.

Option A: Install Redis with Docker (Recommended)#

Docker makes Redis installation incredibly simple. No complex installations, no configuration files to edit.

Prerequisite: Install Docker on your machine first if you haven't already.

Step 1: Pull the Redis Image#

Open your terminal and run:

docker pull redis

This downloads the latest Redis image from Docker Hub.

Step 2: Run Redis Container#

docker run -d --name redis-cache -p 6379:6379 redis

What this does:

• -d - Runs in detached mode (background)
• --name redis-cache - Names the container for easy reference
• -p 6379:6379 - Maps Redis port to your local machine
• redis - The image to use

Step 3: Verify Redis is Running#

docker ps

You should see your redis-cache container running. Test the connection:

docker exec -it redis-cache redis-cli ping

Expected output: PONG ✅

Congratulations! Redis is now running on your machine.

Option B: Install Redis Natively (Without Docker)#

If you prefer not to use Docker, install Redis directly on your system:

macOS (Homebrew):

brew install redis
brew services start redis

Ubuntu/Debian:

sudo apt update
sudo apt install redis-server -y
sudo systemctl start redis-server
sudo systemctl enable redis-server

Windows:

Download and run the Redis for Windows installer or use WSL2 with the Ubuntu commands above.

Verify the installation:

redis-cli ping

Expected output: PONG ✅

---

2. Set Up SQL Server Database#

Caching shines when you have data worth caching. Let's create a simple Products table that simulates a real e-commerce scenario. This gives us something tangible to measure against.

For this tutorial, we'll create a simple Products database to demonstrate caching.

Database Schema#

CREATE TABLE Products (
    ProductId INT PRIMARY KEY IDENTITY(1,1),
    Name NVARCHAR(200) NOT NULL,
    Description NVARCHAR(1000),
    Price DECIMAL(18,2) NOT NULL,
    Category NVARCHAR(100) NOT NULL,
    CreatedDate DATETIME2 NOT NULL DEFAULT GETUTCDATE()
);

Sample Data#

Let's insert some sample products:

INSERT INTO Products (Name, Description, Price, Category, CreatedDate)
VALUES 
    ('Laptop Pro 15', 'High-performance laptop with 16GB RAM', 1299.99, 'Electronics', GETUTCDATE()),
    ('Wireless Mouse', 'Ergonomic wireless mouse', 29.99, 'Accessories', GETUTCDATE()),
    ('USB-C Hub', '7-in-1 USB-C hub with HDMI', 49.99, 'Accessories', GETUTCDATE()),
    ('Monitor 27"', '4K UHD monitor with HDR support', 449.99, 'Electronics', GETUTCDATE()),
    ('Mechanical Keyboard', 'RGB backlit mechanical keyboard', 129.99, 'Accessories', GETUTCDATE());

Run this script in SQL Server Management Studio or Azure Data Studio.

---

3. Build the .NET Application#

Here's where things get interesting. We're going to build an API that looks normal on the surface, but under the hood, it's checking Redis before every database call. The caller won't know the difference, they'll just notice everything is faster.

Step 1: Create the Project#

dotnet new webapi -n RedisDemo
cd RedisDemo

Step 2: Install Required Packages#

dotnet add package StackExchange.Redis
dotnet add package Microsoft.Data.SqlClient
dotnet add package Dapper
dotnet add package Newtonsoft.Json

What each package does:

• StackExchange.Redis - High-performance Redis client
• Microsoft.Data.SqlClient - SQL Server connectivity
• Dapper - Lightweight ORM for data access
• Newtonsoft.Json - JSON serialization for cache

Step 3: Configure Connection Strings#

Update appsettings.json:

{
  "ConnectionStrings": {
    "SqlServer": "Server=localhost;Database=ProductsDB;User Id=sa;Password=YourPassword;TrustServerCertificate=True;",
    "Redis": "localhost:6379"
  },
  "Redis": {
    "CacheExpirationMinutes": 10
  }
}

Step 4: Create the Product Model#

Models/Product.cs:

namespace RedisDemo.Models
{
    public class Product
    {
        public int ProductId { get; set; }
        public string Name { get; set; } = string.Empty;
        public string Description { get; set; } = string.Empty;
        public decimal Price { get; set; }
        public string Category { get; set; } = string.Empty;
        public DateTime CreatedDate { get; set; }
    }
}

---

4. Implement the Cache-Aside Pattern#

This is the heart of the entire guide. The cache-aside pattern is how most production systems handle caching, and once you understand it, you can apply it anywhere.

The idea is simple: check the cache first. If the data exists, return it immediately. If not, fetch from the database, store it in cache for next time, then return it. Here's the flow:

1. Application requests data
2. Check cache first - Is the data in Redis?
3. Cache hit - Return data immediately (fast!)
4. Cache miss - Query database, cache the result, return data

Repository Interface#

Repositories/IProductRepository.cs:

public interface IProductRepository
{
    Task<Product?> GetProductByIdAsync(int productId);
    Task<IEnumerable<Product>> GetAllProductsAsync();
    Task<bool> UpdateProductAsync(Product product);
    Task<bool> DeleteProductAsync(int productId);
}

Repository Implementation (The Magic!)#

Repositories/ProductRepository.cs:

using Dapper;
using Microsoft.Data.SqlClient;
using Newtonsoft.Json;
using StackExchange.Redis;

public class ProductRepository : IProductRepository
{
    private readonly string _connectionString;
    private readonly IDatabase _cache;
    private readonly int _cacheExpirationMinutes;

    public ProductRepository(IConfiguration configuration, IConnectionMultiplexer redis)
    {
        _connectionString = configuration.GetConnectionString("SqlServer")!;
        _cache = redis.GetDatabase();
        _cacheExpirationMinutes = configuration.GetValue<int>("Redis:CacheExpirationMinutes", 10);
    }

    public async Task<Product?> GetProductByIdAsync(int productId)
    {
        // Step 1: Try to get from cache first
        string cacheKey = $"product:{productId}";
        
        try
        {
            var cachedProduct = await _cache.StringGetAsync(cacheKey);
            
            if (!cachedProduct.IsNullOrEmpty)
            {
                // Cache hit! Deserialize and return
                Console.WriteLine($"✅ Cache HIT for product {productId}");
                return JsonConvert.DeserializeObject<Product>(cachedProduct!);
            }
        }
        catch (Exception ex)
        {
            // Log cache error but continue to database
            Console.WriteLine($"⚠️ Cache error: {ex.Message}");
        }

        // Step 2: Cache miss - fetch from database
        Console.WriteLine($"❌ Cache MISS for product {productId} - Querying database");
        
        using var connection = new SqlConnection(_connectionString);
        var product = await connection.QueryFirstOrDefaultAsync<Product>(
            "SELECT * FROM Products WHERE ProductId = @ProductId",
            new { ProductId = productId }
        );

        // Step 3: If product found, cache it
        if (product != null)
        {
            try
            {
                var serializedProduct = JsonConvert.SerializeObject(product);
                await _cache.StringSetAsync(
                    cacheKey,
                    serializedProduct,
                    TimeSpan.FromMinutes(_cacheExpirationMinutes)
                );
                Console.WriteLine($"💾 Product {productId} cached for {_cacheExpirationMinutes} minutes");
            }
            catch (Exception ex)
            {
                // Log cache error but return the product anyway
                Console.WriteLine($"⚠️ Failed to cache product: {ex.Message}");
            }
        }

        return product;
    }

    public async Task<bool> UpdateProductAsync(Product product)
    {
        using var connection = new SqlConnection(_connectionString);
        
        var result = await connection.ExecuteAsync(
            @"UPDATE Products 
              SET Name = @Name, Description = @Description, 
                  Price = @Price, Category = @Category 
              WHERE ProductId = @ProductId",
            product
        );

        // Invalidate cache for this product
        if (result > 0)
        {
            await _cache.KeyDeleteAsync($"product:{product.ProductId}");
            await _cache.KeyDeleteAsync("products:all");
            Console.WriteLine($"🗑️ Cache invalidated for product {product.ProductId}");
        }

        return result > 0;
    }
}

Key Points in This Implementation:#

1. Graceful Degradation - If Redis fails, the app still works by falling back to the database
2. Cache Invalidation - When data changes, we remove it from cache to ensure consistency
3. TTL (Time To Live) - Cached data expires after 10 minutes to prevent stale data
4. Logging - Console output helps debug cache behavior

---

5. Set Up Dependency Injection#

Now we need to wire everything together. This is where .NET's dependency injection shines. We'll register Redis as a singleton (because connections are expensive to create) and our repository as scoped (one instance per request).

Program.cs:

using StackExchange.Redis;
using RedisDemo.Repositories;

var builder = WebApplication.CreateBuilder(args);

// Add controllers and Swagger
builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// Configure Redis
var redisConnectionString = builder.Configuration.GetConnectionString("Redis")!;
builder.Services.AddSingleton<IConnectionMultiplexer>(sp =>
{
    var configuration = ConfigurationOptions.Parse(redisConnectionString);
    configuration.AbortOnConnectFail = false; // Don't fail if Redis is temporarily unavailable
    configuration.ConnectRetry = 3;
    configuration.ConnectTimeout = 5000;
    
    return ConnectionMultiplexer.Connect(configuration);
});

// Register repositories
builder.Services.AddScoped<IProductRepository, ProductRepository>();

var app = builder.Build();

// Test Redis connection on startup
try
{
    var redis = app.Services.GetRequiredService<IConnectionMultiplexer>();
    var db = redis.GetDatabase();
    await db.PingAsync();
    Console.WriteLine("✅ Successfully connected to Redis!");
}
catch (Exception ex)
{
    Console.WriteLine($"⚠️ Failed to connect to Redis: {ex.Message}");
}

app.UseSwagger();
app.UseSwaggerUI();
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

---

6. Create the API Controller#

The controller is intentionally simple. It doesn't know anything about caching. It just calls the repository and returns the result. All the caching logic is hidden away where it belongs.

Controllers/ProductsController.cs:

using Microsoft.AspNetCore.Mvc;
using RedisDemo.Models;
using RedisDemo.Repositories;

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductRepository _productRepository;

    public ProductsController(IProductRepository productRepository)
    {
        _productRepository = productRepository;
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<Product>> GetProduct(int id)
    {
        var product = await _productRepository.GetProductByIdAsync(id);
        
        if (product == null)
        {
            return NotFound(new { message = $"Product with ID {id} not found" });
        }

        return Ok(product);
    }

    [HttpGet]
    public async Task<ActionResult<IEnumerable<Product>>> GetAllProducts()
    {
        var products = await _productRepository.GetAllProductsAsync();
        return Ok(products);
    }

    [HttpPut("{id}")]
    public async Task<ActionResult> UpdateProduct(int id, [FromBody] Product product)
    {
        if (id != product.ProductId)
        {
            return BadRequest(new { message = "Product ID mismatch" });
        }

        var success = await _productRepository.UpdateProductAsync(product);
        
        if (!success)
        {
            return NotFound(new { message = $"Product with ID {id} not found" });
        }

        return Ok(new { message = "Product updated and cache invalidated" });
    }
}

---

7. Test the Performance#

Let's see the dramatic difference caching makes!

Run the Application#

dotnet run

Open your browser to https://localhost:7xxx to see Swagger UI.

Test 1: First Request (Cache Miss)#

Make a GET request to /api/products/1

Console Output:

❌ Cache MISS for product 1 - Querying database
💾 Product 1 cached for 10 minutes

Response Time: ~150ms

Test 2: Second Request (Cache Hit)#

Make the same request again to /api/products/1

Console Output:

✅ Cache HIT for product 1

Response Time: ~5ms

The Results: 30x Faster! 🚀#

---

8. View Cache Data in Redis#

Let's peek inside Redis to see what's cached:

# Connect to Redis CLI
docker exec -it redis-cache redis-cli

# View all cached keys
KEYS *

# Output:
# 1) "product:1"
# 2) "product:2"
# 3) "products:all"

# Get a specific product from cache
GET product:1

# Output (JSON):
# {"ProductId":1,"Name":"Laptop Pro 15","Description":"...","Price":1299.99,...}

# Check how long until it expires (TTL)
TTL product:1

# Output (seconds remaining):
# 587

# Exit
EXIT

---

9. Cache Invalidation in Action#

One of the most critical aspects of caching is keeping data fresh. Let's see cache invalidation in action.

Update a Product#

Make a PUT request to /api/products/1:

{
  "productId": 1,
  "name": "Laptop Pro 15 - UPDATED",
  "description": "Now with 32GB RAM!",
  "price": 1499.99,
  "category": "Electronics"
}

Console Output:

🗑️ Cache invalidated for product 1
🗑️ Cache invalidated for products:all

Verify Fresh Data#

Next GET request to /api/products/1:

Console Output:

❌ Cache MISS for product 1 - Querying database
💾 Product 1 cached for 10 minutes

The cache was cleared, so fresh data was fetched from the database and cached again. Users always see up-to-date information!

---

10. Best Practices for Production#

Now that you have a working implementation, let's discuss production-ready practices.

Set Appropriate TTL (Time To Live)#

// Different TTL for different data types
var productTTL = TimeSpan.FromMinutes(10);      // Product catalogs
var userSessionTTL = TimeSpan.FromHours(1);     // User sessions
var configTTL = TimeSpan.FromHours(24);         // Configuration data

Rule of thumb:

• Frequently changing data: 1-5 minutes
• Moderately stable data: 10-30 minutes
• Rarely changing data: 1-24 hours

Use Clear Key Naming Conventions#

// Good - hierarchical and descriptive
"product:123"
"user:456:cart"
"category:electronics:products"

// Bad - unclear and unmaintainable
"p123"
"data_456"
"temp_cache_1"

Handle Cache Failures Gracefully#

try
{
    // Try cache first
    var cached = await _cache.StringGetAsync(key);
    if (!cached.IsNullOrEmpty) return DeserializeData(cached);
}
catch (Exception ex)
{
    // Log but don't fail - fallback to database
    _logger.LogWarning($"Cache error: {ex.Message}");
}

// Fallback to database
return await GetFromDatabase(id);

Monitor Cache Performance#

Track these metrics:

public class CacheMetrics
{
    public long CacheHits { get; set; }
    public long CacheMisses { get; set; }
    public double HitRate => (double)CacheHits / (CacheHits + CacheMisses) * 100;
}

// Goal: 80%+ hit rate

Implement Cache Warming#

For critical data, pre-populate the cache:

public async Task WarmCache()
{
    var topProducts = await GetTopSellingProducts();
    foreach (var product in topProducts)
    {
        await CacheProduct(product);
    }
}

Use Redis Connection Pooling#

// Register as Singleton - connections are expensive to create
builder.Services.AddSingleton<IConnectionMultiplexer>(sp =>
{
    var config = ConfigurationOptions.Parse(redisConnectionString);
    config.AbortOnConnectFail = false;
    config.ConnectRetry = 3;
    config.ConnectTimeout = 5000;
    config.KeepAlive = 180;
    return ConnectionMultiplexer.Connect(config);
});

Secure Your Redis Instance#

# Enable authentication
redis-cli CONFIG SET requirepass "your-secure-password"

# Update connection string
"Redis": "localhost:6379,password=your-secure-password"

Production checklist:

• ✅ Enable authentication
• ✅ Bind to localhost or use VPC
• ✅ Enable TLS/SSL for encryption
• ✅ Use Redis ACL for fine-grained access control
• ✅ Never expose Redis to the public internet

---

11. Common Pitfalls to Avoid#

Pitfall 1: Caching Too Much#

Problem: Caching everything wastes memory and provides no benefit for rarely accessed data.

Solution: Cache only frequently accessed data (80/20 rule - 20% of data gets 80% of requests).

Pitfall 2: No Cache Expiration#

Problem: Data becomes stale and users see outdated information.

Solution: Always set TTL. Even long-lived data should expire eventually.

Pitfall 3: Cache Stampede#

Problem: When cache expires, thousands of concurrent requests hit the database simultaneously.

Solution: Implement cache locking or use "soft" expiration:

// Refresh cache in background before it expires
if (timeUntilExpiry < TimeSpan.FromMinutes(1))
{
    _ = Task.Run(() => RefreshCacheInBackground(key));
}

Pitfall 4: Storing Large Objects#

Problem: Redis performance degrades with objects over 1MB.

Solution:

• Store only essential data
• Split large objects into smaller chunks
• Consider object storage (S3, Azure Blob) for large files

Pitfall 5: Forgetting to Invalidate#

Problem: Cached data stays stale even after updates.

Solution: Automatically invalidate cache on all update/delete operations:

public async Task UpdateProduct(Product product)
{
    await UpdateInDatabase(product);
    await InvalidateCache($"product:{product.Id}");  // Don't forget!
    await InvalidateCache("products:all");            // Related caches too!
}

---

12. When to Use Redis Caching#

✅ Perfect Use Cases#

E-commerce Applications

• Product catalogs (rarely change)
• Shopping carts (session-based)
• User preferences
• Search results

Social Media

• User feeds
• Notification counts
• Trending topics
• Leaderboards

Content Platforms

• Article content
• Comments
• User profiles
• Recommendations

APIs

• Rate limiting
• Response caching
• Authentication tokens
• Configuration data

❌ Poor Use Cases#

Financial Transactions

• Require ACID guarantees
• Cannot tolerate stale data
• Better suited for databases

Real-time Stock Prices

• Changes every second
• Cache becomes instantly stale
• Direct database queries better

Large Media Files

• Videos, large images
• Better suited for CDN or object storage
• Would consume too much Redis memory

Single-User Desktop Apps

• No benefit from distributed cache
• In-memory caching sufficient

---

13. Scaling Redis for Production#

As your application grows, you'll need to scale Redis.

Vertical Scaling#

Increase Resources:

• Add more RAM (Redis is memory-bound)
• Use faster CPUs
• Improve network throughput

When to use: Initial growth phase, simpler to implement.

Horizontal Scaling#

Redis Cluster:

• Automatic data sharding across nodes
• High availability with master-slave replication
• No single point of failure

# Create a 6-node cluster (3 masters, 3 slaves)
redis-cli --cluster create \
  node1:6379 node2:6379 node3:6379 \
  node4:6379 node5:6379 node6:6379 \
  --cluster-replicas 1

When to use: Large-scale applications with high traffic.

Managed Redis Services#

AWS ElastiCache for Redis

• Fully managed
• Automatic backups
• Multi-AZ availability
• Easy scaling

Azure Cache for Redis

• Enterprise-grade SLA
• Built-in monitoring
• Geo-replication
• Integration with Azure services

Redis Enterprise Cloud

• Official Redis offering
• Active-active geo-distribution
• Advanced features
• Expert support

---

14. Monitoring and Observability#

You can't improve what you don't measure. Here's what to monitor:

Key Metrics#

# Memory usage
redis-cli INFO memory

# Key metrics to watch:
# - used_memory_human: Total memory used
# - used_memory_peak_human: Peak memory usage
# - mem_fragmentation_ratio: Should be close to 1.0

# Cache statistics
redis-cli INFO stats

# Key metrics:
# - keyspace_hits: Cache hits
# - keyspace_misses: Cache misses
# - evicted_keys: Keys removed due to memory pressure
# - expired_keys: Keys that expired naturally

# Client connections
redis-cli CLIENT LIST

# Slow queries (over 10ms)
redis-cli SLOWLOG GET 10

Calculate Cache Hit Rate#

var info = await _cache.Execute("INFO", "stats");
var lines = info.ToString().Split('\n');

var hits = GetValue(lines, "keyspace_hits");
var misses = GetValue(lines, "keyspace_misses");

var hitRate = (double)hits / (hits + misses) * 100;

Console.WriteLine($"Cache Hit Rate: {hitRate:F2}%");

// Target: 80%+

Set Up Alerts#

Alert when:

• Hit rate drops below 70%
• Memory usage exceeds 80%
• Connection failures increase
• Response time spikes

---

15. Real-World Success Story#

Let me share a specific example that changed how I think about caching.

The Situation: I was working on a B2B inventory management system for a manufacturing company. Their product catalog had 50,000+ SKUs, and every time a warehouse worker scanned an item, the app hit the database to fetch product details, stock levels, and location data. One query per scan. Workers scanning 200+ items per hour. Multiply that across 15 warehouses.

The database was dying. Response times crept from 100ms to 800ms during peak hours. Workers started complaining that the app was "unusable." Management was talking about buying more database capacity.

Here's what I realized: 95% of those scans were for the same 500 products. The same popular SKUs, over and over. We were asking the database the same question thousands of times a day.

What We Did: We implemented Redis caching with a twist:

• Product details: 30-minute TTL (rarely change)
• Stock levels: 2-minute TTL (change frequently, but slight staleness acceptable for display)
• Location data: 10-minute TTL

The key insight was using different TTLs based on how often data actually changes, not a blanket expiration for everything.

The Results:

But here's the part that surprised me: we didn't just make it faster. We made it reliable. The app worked the same at 9 AM as it did at 3 PM during shift change. That consistency mattered more to the workers than raw speed.

---

Conclusion#

Here's the truth about performance optimization: most of the time, you don't need a faster database. You don't need more servers. You don't need to rewrite your queries.

You need to stop asking questions you already know the answer to.

That's what Redis gives you. A place to remember. And remembering is fast.

With the patterns in this guide, you can:

• Turn 500ms endpoints into 5ms endpoints
• Handle 10x the traffic without touching your database infrastructure
• Make your app feel instant, even under load

The cache-aside pattern we built here isn't a demo. It's production-ready code that I've shipped to real systems handling real traffic. Copy it. Modify it. Make it yours.

Start small. Pick one endpoint, your slowest one, your most-hit one. Add caching. Measure the difference. Then do it again.

The first time you see that cache hit log and watch your response time drop from hundreds of milliseconds to single digits, you'll wonder why you waited so long.

---

Next Steps#

Ready to implement Redis caching in your application? Here's what to do:

1. Download the complete source code from my GitHub repository
2. Follow the setup guide to get Redis running
3. Start with one endpoint - Pick your most frequently accessed data
4. Measure the improvement - Use the performance stats endpoint
5. Expand gradually - Add caching to more endpoints
6. Monitor in production - Track cache hit rates and adjust

---

Additional Resources#

• 📚 Official Redis Documentation
• 📖 StackExchange.Redis Guide
• 🎓 Redis University - Free Courses
• 💻 Complete Source Code on GitHub

---

Got a Redis caching tip I missed? I'd love to hear it.