1. In computing, a cache is a high-speed data storage layer which stores a subset of data, typically transient in nature, so that future requests for that data are served up faster than is possible by accessing the data’s primary storage location. Caching allows you to efficiently reuse previously retrieved or computed data.

2. The data in a cache is generally stored in fast access hardware such as RAM (Random-access memory) and may also be used in correlation with a software component.

3. A cache's primary purpose is to increase data retrieval performance by reducing the need to access the underlying slower storage layer.

4. What Should You Cache?

   1. Data that requires an slow and expensive query to acquire.

   2. Relatively static and frequently accessed data.

   3. Information that can be stale for an extended period.

5. Benefits of caching

   1. Improved application speed

   2. Reduced resource burden of time-consuming database queries

   3. Reduced response latency

6. Caching Types:

   1. Client Caching: With client-side caching, data is typically stored in a browser rather than making repeated queries to a web server. HTTP cache headers provide the details on how long the browser can fulfill future responses from the cache for the stored web content.

   2. Server Caching: With server-side caching, various web caching techniques can be used to improve the performance of a website by providing caching in between the data's source and the client.

7. Caching Types:

1. Amazon's global content delivery network (CDN)

2. Accelerates delivery of your websites, APIs, video content, or other web assets

3. Integrates with other AWS products

4. Pay-per-use, with no long-term commitments or minimum fees required

5. Offers a multi-tier cache by default

6. Uses regional edge caches to improve latency and lower the load on your origin servers

7. Provides an additional layer of security for your architectures

8. Supports real-time, bidirectional communication over the WebSocket protocol

9. Deploy

   1. You specify an origin server, like an Amazon S3 bucket or your own HTTP server, from which CloudFront gets your files. These will be distributed from CloudFront edge locations all over the world. Your HTTP server can run on an Amazon EC2 instance or on servers you manage on premises.

   2. You create a CloudFront distribution, which tells CloudFront which origin servers to get your files from when users request the files through your web site or application. At the same time, you specify details such as whether you want CloudFront to log all requests and whether you want the distribution to be enabled as soon as it's created.

   3. CloudFront assigns a domain name to your new distribution.

   4. CloudFront sends your distribution's configuration, but not the content, to all of its edge locations. Edge locations are collections of servers in geographically dispersed data centers where CloudFront caches copies of your objects.

10. Three ways to expire content

    1. Time to Live: If you set the TTL for a particular origin to 0, CloudFront will still cache the content from that origin. CloudFront will then make a GET request with an If-Modified-Since header, which gives the origin a chance to signal that CloudFront can continue to use the cached content if it hasn't changed at the origin.

    2. Change Object Name: The second way requires more effort but is immediate (some CMS systems support this). Although you can update existing objects in a CloudFront distribution and use the same object names, it is not recommended. CloudFront distributes objects to edge locations only when the objects are requested, not when you put new or updated objects in your origin. If you update an existing object in your origin with a newer version that has the same name, an edge location won’t get that new version from your origin until both of the listed events occur.

    3. Invalidate the Object: The third method should only be used sparingly for individual objects: it is a bad solution (the system must forcibly interact with all edge locations).

1. Web service used to deploy, operate, and scale an in-memory cache in the cloud

2. Improves the performance of web apps by allowing you to retrieve information from fast, managed, in-memory data stores, instead of relying on slower disk-based databases

3. Whenever possible, apps will retrieve data from ElastiCache and defer to databases when data isn't found in cache.

4. You can abstract the HTTP sessions from the web servers themselves, and a common solution for this is to leverage an in-memory key/value store such as Redis, Memcached or Dynamo DB.

5. 
   

1. You are concerned about response times for your customer

2. You find heavy-hitting, high-volume requests inundating your database

3. You would like to reduce your database costs

4. 2 Forms to manage with ElasticCache:

   1. Write through: The write-through strategy adds data or updates data in the cache whenever data is written to the database. Advantages:Every write involves two trips: A write to the cache & A write to the database, Disadvantages: Missing data ( If you spin up a new node, whether due to a node failure or scaling out, there is missing data.), and Cache churn (Most data is never read, which is a waste of resources)

   2. Lazy loading: lazy loading is a caching strategy that loads data into the cache only when necessary. Advantages: Only requested data is cached, and Node failures aren't fatal for your application. Disadvantages: There is a cache miss penalty. Each cache miss results in three trips, and Stale data.

   3. 
      

5. 
   

Write Through

Lazy loading

Caching info using ElastiCache - TTL

1. Content