Caching with ElastiCache

In part eight we built a strong database. But imagine your store's home page shows the same 20 products to every visitor. Thousands of visitors means the database runs the same query thousands of times and returns the same answer.

The solution is simple: keep the answer somewhere fast, and go back to it instead of asking the database every time. That's a cache.

What a cache is #

A cache is a temporary copy of data that takes time or effort to fetch. Memory is far faster than disk, so an answer usually arrives in under a millisecond. That gives you:

• Higher speed for the user.
• Less load on the database, so you can serve more visitors with a smaller one.

The key rule: a cache isn't the source of truth. If you lose all of it, your application gets a bit slower, but no important data is lost.

ElastiCache is a managed cache service: AWS handles the servers, patches and failover. Unlike RDS, though, you have to change your application's code, because the application decides what to store and when to read it.

Choosing an engine #

You have two ways to run it:

How your application uses it #

Lazy loading #

This is the most common approach, also called cache-aside: your application asks the cache first, goes to the database if the answer isn't there, then stores the answer for next time.

In code, it looks roughly like this:

def get_product(product_id):
    key = f"product:{product_id}"

    cached = cache.get(key)
    if cached:
        return json.loads(cached)

    product = db.fetch_product(product_id)
    cache.set(key, json.dumps(product), ex=300)  # Valid for 5 minutes
    return product

• Pros: it stores only what's actually requested, and if the cache fails the application carries on from the database.
• Cons: the first request is slow, and data can be stale until it expires.

Write-through #

Whenever you write to the database, you write to the cache as well.

• Pros: the cache is always current.
• Cons: an extra write every time, and the cache can fill with data nobody reads.

Many applications combine the two: lazy loading, plus updating the cache on writes for important data.

TTL and eviction #

Each key has a lifetime (TTL) after which it disappears, so stale data doesn't stay forever. The right value depends on the data:

When memory fills up, the cache evicts some keys, usually the least used. If this happens a lot, your cache is too small.

More than a cache #

Sessions: remember the table in part seven? When you keep sessions in ElastiCache, any server can read them, so users don't get signed out when their server disappears.

Leaderboards: a sorted set keeps items ordered by score and gives you the top entries instantly, instead of sorting millions of rows in the database.

Rate limiting: an INCR counter with a TTL counts each user's requests per minute and blocks anyone over the limit.

Security and monitoring #

• Network: by default the cache is reachable only from inside your network, so let its security group accept traffic only from the servers' security group.
• Encryption: turn it on in transit and at rest; it's always on with Serverless.
• Access: use users and permissions or IAM authentication on Valkey and Redis, and SASL on Memcached.

In CloudWatch, watch these metrics:

Hands-on: a cache and a leaderboard #

We'll use your server from part three. From CloudShell, create a security group that accepts traffic from the server's security group. Serverless uses ports 6379 and 6380:

aws ec2 create-security-group --group-name cache-sg \
  --description "Cache access" --query GroupId --output text

aws ec2 authorize-security-group-ingress --group-id sg-CACHE-GROUP \
  --protocol tcp --port 6379-6380 --source-group sg-SERVER-GROUP

Then create the cache using the ID you got back:

aws elasticache create-serverless-cache \
  --serverless-cache-name series-cache \
  --engine valkey \
  --security-group-ids sg-CACHE-GROUP

aws elasticache describe-serverless-caches \
  --serverless-cache-name series-cache \
  --query "ServerlessCaches[0].[Status,Endpoint.Address]" --output table

When the status shows available, sign in to the server through EC2 Instance Connect and connect:

sudo dnf install -y valkey
valkey-cli -h YOUR-CACHE-ENDPOINT --tls -c -p 6379

Try a TTL:

SET product:1 "Keyboard"
GET product:1

SET offer:today "20% off" EX 30
TTL offer:today

Repeat TTL a few times and watch the countdown. After 30 seconds, GET offer:today returns (nil).

Now a leaderboard:

ZADD leaderboard 120 sara 300 omar 90 lina
ZINCRBY leaderboard 250 lina
ZREVRANGE leaderboard 0 2 WITHSCORES

You'll see lina in first place with 340 points, with no sorting on your side. Leave with exit.

aws elasticache delete-serverless-cache --serverless-cache-name series-cache

aws ec2 delete-security-group --group-id sg-CACHE-GROUP

Summary #

• A cache is a fast, temporary copy, not the source of truth.
• Start with Valkey, and with Serverless if your load is irregular or you want an easy start.
• Lazy loading is the most common approach, and write-through keeps the cache current.
• The TTL sets how much staleness you accept, and some data shouldn't be cached at all.
• It also works for sessions, leaderboards and rate limiting.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

You now know RDS, Aurora and ElastiCache, and AWS has many more. In part ten we answer the question that confuses everyone: which database should you choose?