Amazon ElastiCache (Valkey) for e-commerce applications

An e-commerce application benefits from an in-memory cache layer between the application servers and the database. Amazon ElastiCache running Valkey provides sub-millisecond read latency for frequently accessed data — product catalog entries, inventory counts, search results, and user sessions — reducing database load and improving response times during traffic spikes.

Cluster configuration

Choose a cluster type based on your data volume, throughput requirements, and operational preferences.

For most e-commerce applications starting out, Serverless provides the simplest path to production. Migrate to node-based clusters when you have predictable traffic baselines and need more control over cluster topology, node types, and scaling behavior.

Key design for product data

Design cache keys to be predictable, debuggable, and scoped to avoid collisions across data types.

Key design best practices:

TTL strategy by data type

Set TTL (time-to-live) values based on how frequently data changes and how stale it can be without affecting the customer experience.

Cache-aside pattern

The cache-aside pattern (also called lazy loading) is the most common caching strategy for e-commerce applications. Your application checks the cache first, and only queries the database on a cache miss.

Read path (pseudocode)

FUNCTION getProduct(productId):
    cacheKey = "product:" + productId

    // Step 1: Check the cache
    cachedValue = cache.GET(cacheKey)

    IF cachedValue exists:
        RETURN deserialize(cachedValue)    // Cache hit — sub-millisecond

    // Step 2: Cache miss — query database
    product = database.query("SELECT * FROM products WHERE id = ?", productId)

    IF product not found:
        RETURN null

    // Step 3: Write to cache with TTL
    cache.SET(cacheKey, serialize(product), EXPIRE = 300)    // 5 minutes

    RETURN product

Write path (pseudocode)

FUNCTION updateProduct(productId, updatedFields):
    // Step 1: Update the database (source of truth)
    database.update("UPDATE products SET ... WHERE id = ?", updatedFields, productId)

    // Step 2: Invalidate the cache (don't update it)
    cache.DELETE("product:" + productId)

    // Next read will trigger a cache miss and repopulate from database

Handling cache failures

FUNCTION getProductWithFallback(productId):
    TRY:
        RETURN getProduct(productId)    // Normal cache-aside path
    CATCH cacheConnectionError:
        // Cache is unavailable — fall back to database directly
        RETURN database.query("SELECT * FROM products WHERE id = ?", productId)
        // Log the error, trigger an alarm, but don't fail the request

Design your application so cache failure degrades performance (slower responses) but doesn't break functionality. The database serves as the fallback.

Cache invalidation strategies

Invalidation ensures users see current data after updates. Choose a strategy based on how quickly changes must be visible.

For marketplace applications that also use Amazon CloudFront as a CDN layer, coordinate invalidation across both tiers: delete the ElastiCache key and send a CloudFront cache invalidation (or cache-tag invalidation) so users see updated content at both the application and edge layers.

Connection management

Key metrics to monitor

Frequently asked questions

When should I use Serverless vs. node-based?

Use Serverless when your traffic is unpredictable (new marketplace, seasonal spikes), when you want to avoid capacity planning, or when your team doesn't have caching operations expertise. Switch to node-based when your traffic patterns are stable, you need fine-grained control over sharding, or your sustained throughput makes node-based more cost-effective.

Should I use Valkey or Redis OSS?

Use Valkey for new deployments. Valkey is the default engine for new ElastiCache clusters, is fully compatible with Redis OSS commands and data structures, and receives continued development. Existing Redis OSS clusters continue to work — migrate to Valkey when convenient using the in-place engine upgrade.

What happens when the cache is unavailable?

Your application should treat the cache as an optimization, not a dependency. If the cache is unavailable, fall back to querying the database directly. Response times will be higher, but the application remains functional. With Multi-AZ enabled, complete cache unavailability is rare — failover to a replica typically completes in under 30 seconds.

How do I estimate the memory I need?

Calculate: (number of unique items to cache) × (average size per item) × (overhead factor of 1.2 for Valkey data structures). The overhead varies by object size and data type—smaller objects have proportionally higher overhead. For example, 100,000 products at 2 KB each with 1.2x overhead = approximately 240 MB. Add session data, search results, and inventory counts. Start with headroom (use 60% of available memory as your target) and monitor the DatabaseMemoryUsagePercentage metric to adjust.