Caches store data so that future requests for that data can be served faster. It is typically a smaller, faster storage layer that sits between the application and a larger, slower backing store (e.g., a database or file system).
The application is responsible for reading and writing data to the cache as needed. When data is requested, the application first checks the cache. If the data is found (a cache hit), it is returned to the client.
When the data is found in the cache, it is returned directly to the client.
sequenceDiagram
Client->>Server: GET /data
Server->>Cache: Read data
Server->>Client: 200 OK
When the data is not found in the cache, it is fetched from the backing store, written to the cache, and then returned to the client.
sequenceDiagram
Client->>Server: GET /data
Server->>Cache: Read data
Server->>DB: Read data
Server->>Cache: Write data
Server->>Client: 200 OK
When data is written, it is written to both the cache and the backing store.
sequenceDiagram
participant Client
participant Server
participant Cache
participant Database
Client->>Server: POST /data
par
Server->>Database: Write data
and
Server->>Cache: Write data
end
Server->>Client: 200 OK
Instead of the application managing the cache, a caching layer (e.g., Redis, Memcached) is used to automatically handle reading and writing data to the cache as needed.
When the data is found in the cache, it is returned directly to the client.
sequenceDiagram
Client->>Server: GET /data
Server->>Cache: Read data
Cache->>Server: Return data
Server->>Client: 200 OK
When the data is not found in the cache, it is fetched from the backing store, written to the cache, and then returned to the client.
sequenceDiagram
participant Cl as Client
participant Se as Server
participant Ca as Cache
participant DB as Database
Cl->>Se: GET /data
Se->>Ca: Read data
Ca->>DB: Read data
DB->>Ca: Write data
Ca->>Se: Return data
Se->>Cl: 200 OK
Data is written to the cache and backing store at the same time. I/O completion is only confirmed once data has been written to both places.
sequenceDiagram
Client->>Server: POST /data
Server->>Cache: Write data
Cache->>Database: Write data
Server->>Client: 200 OK
Data is written directly to the backing store, bypassing the cache. The cache is only updated when data is read.
sequenceDiagram
participant Client
participant Server
participant Database
Client->>Server: POST /data
Server->>Database: Write data
Server->>Client: 200 OK
Data is written to the cache only. The cache asynchronously writes data to the backing store at a later time.
sequenceDiagram
participant Client
participant Server
participant Cache
participant Database
Client->>Server: POST /data
Server->>Cache: Write data
Server->>Client: 200 OK
Note over Server, Database: Asynchronous write to Database
Server-->>Database: Write data
TTL (Time-To-Live) is a common eviction policy where cached data is automatically removed after a certain period of time. Other eviction policies include LRU (Least Recently Used), LFU (Least Frequently Used), and FIFO (First In, First Out).
Redis is a versatile in-memory data store that serves as both a cache and a database. It supports complex data structures and provides features like data expiration, which makes it a powerful choice for caching. Redis is often used to cache frequently accessed data, such as user sessions, leaderboard rankings, and real-time analytics.
Memcached is an in-memory key-value store designed for high-performance caching. It is known for its simplicity and efficiency in storing and retrieving data. Developers often use Memcached to cache database query results, API responses, and frequently accessed data in web applications.