# Caching

In simple terms, caching is the technique of storing frequently used data in a place (a subset of the primary storage ), where the retrieval and processing on the data is quick.

ex: **Google** has a highly complex web crawling and indexing algorithm that runs for each search query, so it stores the results of the frequent queries ( hows the weather, calculator, google translate etc) in the cache memory to save computation time when similar requests are made.

ex: **X** or **Twitter** previously, when there is a trending topic, let's say an ongoing global topic like a war or elections of a powerful country etc, the tweets and content around the trending topics are stored in a cache as the algorithm that is designed to catch these trends is computationally taxing, thus the results are cached in memory to be served easily.

Hence, whenever there is a task involving **high data throughput or heavy computation**, caching is preferred.

### Types of Caches:

1.  Network Cache
    
2.  Hardware Cache
    
3.  Software Cache
    

* * *

### Network Cache:

#### CDN (Content Delivery Network):

This a caching mechanism, based on the Delivery of the content requested based on the geographical location of the cache servers.

Lets say the user queried for a video or an Image, the Browser utilises the DNS to route that request to the nearest **PoP** ( Point of presence ) based on different parameters, like: distance of server, quality of internet of the user, the network traffic . Then the query is searched in the cache server, if it exists, its a cache Hit or a cache Miss if it doesn't.

In case of a cache Hit, the content is quickly delivered to the end user, if its a Cache Miss, the content from the main memory ( primary storage ) is served to the user which is slower.

The content that is to be stored and the duration for which to be stored ( TTL - time to live ), is decided before hand .

Ex: Youtube has different qualities of video resolution which it stores in different servers (PoP) across the world like: a viewer from Delhi won't get its video served from the PoP in San Francisco.

#### **DNS (Domain Name System):**

DNS is a distributed system that translates human-readable domain names into machine-readable IP addresses so that browsers can locate the correct server on the internet.

When a user enters a domain name (for example `youtube.com`) in the browser, the browser sends a query to a **Recursive Resolver** (usually provided by the ISP or public services like Google DNS or Cloudflare).

The resolver first checks its **local cache** to see if the IP address already exists. If it is found and the **TTL (Time To Live)** has not expired, the resolver immediately returns the IP address to the browser.

If the record is not found in the cache, the resolver performs a lookup through the DNS hierarchy:

*   **Root Name Server:** The resolver queries a root server, which returns the address of the appropriate **Top Level Domain (TLD)** server (such as `.com`).
    
*   **TLD Server:** The TLD server returns the address of the **Authoritative Name Server** responsible for the domain.
    
*   **Authoritative Name Server:** This server contains the actual DNS records and returns the correct **IP address** of the domain.
    

The resolver sends this IP address back to the browser and caches it for the TTL duration. The browser then uses this IP address to connect to the server and request the required content.

Hence DNS relies heavily on caching on various levels : Browser level, Local Cache, Resolver Cache to prevent all the above steps.

### Hardware Cache:

This is a caching mechanism used to speed up data access by storing frequently requested data in **high-speed memory (RAM)** instead of retrieving it repeatedly from slower storage systems such as disks or databases.

When an application requests data (for example a user profile or product details), the system first checks the **cache layer** to see if the data already exists there.

Since **RAM access is significantly faster than disk access**, this greatly reduces latency and database load, especially for frequently requested data.

In memory caches, are not permanent and are also not present in abundance, hence they have a special use case where we tradeoff the persistence and volume with speed.

**Examples:**  
Technologies like **Redis** and **Memcached** are commonly used as distributed in-memory caching systems. For example, a large website may store frequently accessed data such as session information, API responses, or trending content in Redis so that repeated requests can be served quickly without querying the main database each time.

![](https://cdn.hashnode.com/uploads/covers/68aadddd414d657d099ce880/b769d610-05f5-4f41-a8be-bc190de28f51.png align="center")

**Lazy Caching (Cache Aside):**  
Data is loaded into the cache **only when it is requested**. If a cache miss occurs, the application fetches the data from the database, returns it to the user, and then stores it in the cache for future requests.

**Write-Through Caching:**  
Whenever data is written, it is **simultaneously written to both the cache and the database**. This keeps the cache always consistent with the database but can introduce slightly higher write latency.

#### Eviction Policy:

This refers to the method by which we remove the data from a cache:

1.  **No Eviction**.
    
2.  **LRU (Least Recently Used)**: Evicting the least recently used data when the memory limit is reached.
    
3.  **LFU (Least Frequently Used)**: Evicting the least Frequently used data when the memory is reached.
    
4.  **TTL based Eviction Policy**: The lowest priority data is evicted first. Priority is decided based on the data having the smallest remaining TTL.
    

**Uses of Redis / In-Memory Cache:**

In-memory caching systems like **Redis** or **Memcached** are used to reduce latency and decrease the load on primary databases by storing frequently accessed data in RAM.

*   **Database Query Caching:** Frequently executed queries can be cached so the application does not need to repeatedly query the main database, significantly improving response times.
    
*   **Session Storage:** User session data (login state, tokens, user preferences) can be stored in Redis so that applications can quickly access session information without hitting the database.
    
*   **API Response Caching:** External APIs often charge based on the number of requests. For example, if a website uses a **weather API**, the response can be cached in Redis so repeated requests within a short period return the cached result instead of calling the API again, reducing cost and latency.
    
*   **Rate Limiting:** Redis is commonly used to store counters for how many requests a user has made within a certain time window. Since rate limiting decisions must happen within milliseconds, using SQL databases would introduce higher latency due to slower queries, whereas Redis can update and check counters extremely quickly in memory.
    

* * *

### **Conclusion:**

Modern web applications rely heavily on intelligent caching and efficient infrastructure to remain fast and scalable. Technologies such as CDNs, DNS resolution, and in-memory caching systems like Redis help reduce latency, minimize database load, and deliver content to users with minimal delay. Understanding how these systems interact provides a clearer picture of how large-scale applications maintain performance under heavy traffic.

In the next article, we will explore **background jobs**—how systems handle time-consuming tasks asynchronously to keep applications responsive and efficient.
