5- AWS Serverless:: Caching and Event-Driven Design

When building high-scale, resilient systems on AWS, performance isn't just about writing fast code, it’s about avoiding unnecessary work. A Engineer’s philosophy often boils down to a simple truth: The fastest code is the code that never executes, and the fastest database query is the one you never have to make.

Let’s unpack caching in AWS piece by piece with a few real-world examples.

Layer 1: Edge Caching (AWS CloudFront)

AWS CloudFront is a Content Delivery Network (CDN). Instead of forcing every user around the world to request data from your main servers (say, located in Virginia), CloudFront replicates data across hundreds of data centers globally, called Edge Locations. If a user in London requests an asset, CloudFront serves it from a London edge server.

There are two types of data cached here:

Static assets: Images, CSS, JavaScript files.
Cacheable API responses: Data from your backend that doesn't change frequently (e.g., a product catalog list).

This is controlled using standard web instructions called Cache-Control HTTP headers sent by your application (e.g., Cache-Control: public, max-age=3600 tells CloudFront to hold onto this data for one hour).

Simple Example:

Imagine an e-commerce store. The logo image (logo.png) and the list of product categories (Shoes, Hats, Shirts) rarely change.

The Flow: When User A requests the category list, CloudFront fetches it from your database once, saves a copy at the Edge, and delivers it. When Users B through Z request the same list, your database is never touched; CloudFront handles it entirely at the edge.
Pipeline Invalidation: When the developers deploy a new version of the website code with a new logo, the deployment pipeline automatically runs a command (aws cloudfront create-invalidation) to forcefully wipe the old logo out of CloudFront's memory globally so users immediately see the new one.

Layer 2: Application Layer Caching (Amazon ElastiCache Redis)

When a request gets past CloudFront and hits your backend compute (AWS Lambda), you don't want the application to immediately hit the primary database if it doesn't have to. we can place Amazon ElastiCache Redis here. Redis is an ultra-fast, in-memory data store.

There are a few specific choices here:

Inside the same VPC: A Virtual Private Cloud (VPC) is your private, isolated network in AWS. Putting Lambda and Redis in the same VPC ensures they can talk to each other securely and with incredibly low latency.
Redis over Memcached: Memcached is a simple key-value cache (e.g., store a string, get a string). Redis is much more powerful. It supports richer data structures (like sorted sets, hashes, and lists) and Pub/Sub (Publish/Subscribe), which allows different parts of your application to broadcast events to each other in real-time.

Simple Example:

Think of a gaming leaderboard or a user's active shopping cart session.
Instead of querying a slow disk-based database every time a player scores a point, you use a Redis Sorted Set. Redis handles the math and sorting instantly in memory. If you want to notify other services that a score changed, you use Redis Pub/Sub to broadcast a message: "Player1 just scored!"

Layer 3: Database Caching (Amazon DAX)

Amazon DynamoDB is a NoSQL database that natively delivers single-digit millisecond latency. For 99% of applications, that is incredibly fast. However, for extreme scale, milliseconds aren't fast enough.

DAX (DynamoDB Accelerator) is a specialized, fully managed write-through cache designed exclusively for DynamoDB. It sits directly in front of your DynamoDB tables. While DynamoDB responds in milliseconds (1/1000th of a second), DAX responds in microseconds (1/1,000,000th of a second). Because it is a "write-through" cache, when you write data to DAX, it automatically saves it to DynamoDB for you, ensuring the cache is always up to date.

Compute Optimization: Lambda Execution Context Reuse

AWS Lambda is serverless. When a request comes in, AWS spins up a tiny container (an invocation), runs your code, and then pauses it.

If a Lambda container is spun up from scratch, it's called a Cold Start.
If a container is reused for a subsequent request, it's called a Warm Start.

If you initialize your database or Redis connection inside the main function handler, your code will open and close a new connection on every single request. This destroys performance. By declaring the Redis client outside the handler function (module scope), AWS keeps that connection alive in memory. When a "warm" invocation happens, the Lambda instantly reuses the existing connection.

Simple Example (Code Context):

Instead of doing this (Bad):

exports.handler = async (event) => {
    const redisClient = connectToRedis(); // Opens a connection EVERY time the function runs
    return await redisClient.get("key");
};

Do this (Good):

const redisClient = connectToRedis(); // Module Scope: Runs ONCE during cold start

exports.handler = async (event) => {
    // Reuses the established connection on all warm starts!
    return await redisClient.get("key");
};

Event-Driven Cache Invalidation

Caching has a legendary problem: How do you know when cached data is old (stale) and needs to be deleted? The engineer uses two strategies to solve this:

TTL-based (Time-to-Live): You set an expiration date on data. For example, "Keep this in Redis for 5 minutes, then delete it automatically."
Event-Driven Invalidation: This is where Event-Driven Design shines. Instead of waiting for a timer to run out, your system reacts to data changes (mutations) in real-time. When a user updates their data, an "event" is triggered. A Lambda function listens to this event and immediately deletes ("invalidates") the old cache key.

Simple Example:

Let's look at a profile update feature:

A user updates their profile bio from "Software Engineer" to "Principal Engineer."
The change is saved to the primary database (DynamoDB).
The Event: DynamoDB emits an event via a feature called DynamoDB Streams saying: "Hey, User 123 just changed their bio!"
The React: An isolated Lambda function wakes up automatically because of that event. It doesn't handle the user's web request; its only job is cache maintenance.
The Lambda runs a command to delete the old cache key for User 123 in Redis (redis.del("user:123")).
The next time anyone views User 123's profile, the application sees the cache is empty, fetches the brand-new data from the database, and repopulates the cache.