Sometimes the problem is not where to store the data, but how many times you request it. If your application queries the same information from the database over and over again, you are overloading and slowing it down. The solution is an in-memory cache, and in AWS it’s called ElastiCache. This subchapter explains what it is and why it can transform your application's performance.

Imagine a news website where 100,000 people read the same popular article. Without a cache, each visit makes the application go to the database to fetch the same article, again and again. The database does the same work 100,000 times and gets saturated.

Databases store data on disk, which is relatively slow. What if we stored the most requested data in a much faster place so we don’t bother the database every time?

A cache is a temporary and very fast store where you keep the most frequently accessed data, to serve it instantly without going to the original source (the database).

The key: the cache stores data in RAM memory, which is much faster than disk. Reading from memory takes microseconds.

Analogy: Imagine a chef in a busy restaurant.

• Without cache: every time they need salt, they go down to the basement storeroom (the database, on disk: slow). A thousand dishes = a thousand trips to the basement.
• With cache: they have the salt and most-used ingredients on the countertop, at hand (the cache, in memory: super fast). They only go to the basement for the less common stuff.

The result: dishes are served much faster and the storeroom (the database) gets a break.

ElastiCache is AWS’s managed service for running in-memory caches. It supports two very popular technologies:

In most modern cases, Redis is used for its additional features, but Memcached is still valid for simple caches.

As a managed service (just like RDS), AWS takes care of installation, patching, and infrastructure; you just use the cache.

The most common pattern is called cache-aside. It works like this:

• The first time a piece of data is requested, it’s not in the cache (miss): it’s fetched from the database and stored in the cache.
• The next times, it’s already in the cache (hit): it’s served instantly without touching the database.

Real example: On the news website, the first reader of the popular article causes it to be loaded from the database and stored in the cache. The next 99,999 readers get it directly from the cache, in microseconds, without bothering the database. The website flies and the database barely works.

• Speeding up frequent reads: “hot” data (the most requested) is served from memory.
• Relieving the database: fewer repeated queries = a more rested and cheaper database.
• Storing user sessions: each user’s session information, instantly accessible.
• Leaderboards in games: Redis is excellent for real-time rankings.
• Rate limiting: controlling how many times someone does something in a period.

The most important thing to understand: the cache is temporary and can be lost. It’s not the “source of truth” for your data; it’s a fast copy of what’s already in the database.

Therefore:

• Cached data has a time to live (TTL): it expires after a period so as not to serve outdated information.
• Never use the cache as the only place for important data. The source of truth is always the database; the cache only speeds up access.

The challenge of caches — invalidation: there’s a famous saying in computer science: “there are only two hard things in programming: cache invalidation and naming things.” The challenge is making sure that when data changes in the database, the cached copy is updated or deleted, so you don’t serve stale information. That’s why TTLs and update strategies are used.

• An in-memory cache stores the most requested data in RAM (super fast) so you don’t have to go to the database (disk, slower) every time.
• ElastiCache is AWS’s managed cache service, with Redis (more complete) and Memcached (simpler).
• The typical pattern (cache-aside): check the cache first; if it’s there (hit), instant response; if not (miss), go to the database and save a copy.
• Benefits: speeds up reads and relieves the database. Ideal for “hot” data, sessions, and leaderboards.
• The cache is temporary: use TTL, keep it updated, and never make it the only place for important data.

In the last subchapter of the chapter (and of Part II) we’ll put everything in order: when to use each type of database we’ve seen.