> For the complete documentation index, see [llms.txt](https://awsarch.adot8.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://awsarch.adot8.com/module-12.md).

# Module 12

### Caching Analogy

<figure><img src="/files/eFpCpB4hlyvM6NN6oLvz" alt=""><figcaption></figcaption></figure>

#### Things that should be cached

* Static and frequently accessed data
* Results of computationally intensive calculations
* Results of time-consuming, frequently used, or complex database queries

### Content Delivery Network

* Is a globally distributed system of caching servers&#x20;
* Has intermediary servers between the client and the application
* Caches copies of commonly requested files (static content)
* Delivers a local copy of the requested content from a nearby cache edge or point of presence

#### Types of data that should be cached by CloudFront

<figure><img src="/files/sZsWIEhb0eE7INuLFZ6U" alt=""><figcaption></figcaption></figure>

### CloudFront

* Is a CDN service that delivers content across the globe securely with low latency and high transfer speeds
* Provides high-speed content distribution by delivering through edge locations
* Improves application resiliency from distributed denial of service (DDoS) attacks by leveraging services such as AWS Shield and AWS WAF

| Edge Locations               | Regional Edge caches             |
| ---------------------------- | -------------------------------- |
| A lot and closer to users    | Fewer and farther away frm users |
| Smaller caches               | Bigger caches                    |
| Helps server popular content | Help with les popular content    |

#### CloudFront Operations

<figure><img src="/files/Oh0ToH2djaxcmr9X2x5N" alt=""><figcaption></figcaption></figure>

#### CloudFront Distributions

{% hint style="info" %}
Used for when you ant CloudFront to distribute your content
{% endhint %}

<figure><img src="/files/txnOFvG6vJKKyxRlfYL8" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/K8wuC0870RglDkh0HyT4" alt=""><figcaption></figcaption></figure>

### Elasticache

<figure><img src="/files/2nfYuVbNxAjjhiQlTI99" alt=""><figcaption></figcaption></figure>

* Is a fully managed, key-value, in-memory data store with sub-millisecond latency
* Sits between an application and an origin data store
* Decreases access latency and eases the load of databases and applications
* Provides a high performance and cost-effective in-memory cache&#x20;
* Is fully compatible with open source Redis and Memcached engines

### Two Types

#### ElastiCache for Memcached

<figure><img src="/files/gd1aoDksl4H8HJHi9xp1" alt=""><figcaption></figcaption></figure>

#### Elasticache for Redis

<figure><img src="/files/MQCCCEAzEQiLeIxWsIX0" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
A time to live must be set for the cached data
{% endhint %}

#### Handling Stale Data

| Lazy Loading                                                                             | Write-Through                                                                                   |
| ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| This strategy updates the cache after the data is requested                              | This strategy updates the cache immediately after updating the primary database                 |
| The cache contains only data that the application actually requests                      | The cache is up-to-date with the primary database (most likely data will be found in the cache) |
| This strategy requires a programmatic strategy to handle keeping the cache as up to date | This strategy results in an increase in cost from storing data in-memory that you might not use |

#### Lazy Loading Operations

{% hint style="info" %}
The information won't update the cache until it gets a **READ** request from a user
{% endhint %}

<figure><img src="/files/37EiU3Hjk0q5o2I8WHTL" alt=""><figcaption></figcaption></figure>

#### Write-Through Operations

{% hint style="info" %}
Real-time updating of the cache
{% endhint %}

<figure><img src="/files/bVPcLFf3itLq6dLgWKLh" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://awsarch.adot8.com/module-12.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.