Caching System

Relevant source files

The following files were used as context for generating this wiki page:

• config/cache.php
• database/migrations/0001_01_01_000001_create_cache_table.php
• config/database.php
• config/app.php
• phpunit.xml
• README.md

The Caching System in this project provides a unified API for various caching backends, allowing the application to store frequently accessed data in high-performance storage to reduce latency and database load. It supports multiple storage drivers, including file-based storage, relational databases, and in-memory stores like Redis or Memcached.

Sources: README.md:12-16, config/cache.php:3-14

System Architecture

The caching architecture is built around "stores," which are specific instances of cache drivers configured with unique settings. A default store is defined for general use, but the application can interact with multiple stores simultaneously. The system also supports a "failover" mechanism to ensure availability.

Cache Stores and Drivers

Each store utilizes a specific driver that dictates the underlying storage mechanism. The following diagram illustrates the relationship between the application and the configured cache stores.

The diagram shows how the Cache Manager routes requests to different storage backends based on the configuration.
Sources: config/cache.php:18-87, config/cache.php:26-28

Configuration and Drivers

The system is primarily configured via config/cache.php. This file defines the default store, the available connections, and global settings such as key prefixing.

Global Settings

To avoid key collisions when multiple applications share the same storage (e.g., a single Redis instance), a prefix is automatically generated. By default, it uses a slug of the application name followed by -cache-.

Option	Description	Default Value
default	The primary store used for caching operations.	database (via env)
prefix	String prepended to all cache keys.	laravel-cache- (slugified)

Sources: config/cache.php:26-28, config/cache.php:91-104

Driver Specifications

The system supports a wide range of drivers, each suited for different environments:

• Database: Stores cached items in a relational database table. It is the default for fresh installations.
• File: Stores items in the local filesystem under storage/framework/cache/data.
• Redis: Uses the redis database connection defined in config/database.php.
• Array: Stores items in a simple PHP array; data is not persisted across requests (primarily used for testing).
• Failover: A special driver that attempts to use a list of stores in sequence if the primary one fails.

Sources: config/cache.php:30-87, phpunit.xml:43

Database Schema

When using the database driver, the system requires specific tables to manage data and atomic locks. These are created via system migrations.

Cache Table Structure

The cache table stores the actual data, while cache_locks handles concurrency control.

The ER diagram represents the schema for persistent database caching.
Sources: database/migrations/0001_01_01_000001_create_cache_table.php:13-23

Data Model Fields

Table	Field	Type	Description
cache	key	string	The unique cache key (Primary Key).
cache	value	mediumText	The cached content.
cache	expiration	integer	Expiry time as an indexed integer.
cache_locks	owner	string	The identifier for the process holding the lock.

Sources: database/migrations/0001_01_01_000001_create_cache_table.php:15-22

Integration with Other Systems

The caching system is a foundational component used by other framework features:

1. Maintenance Mode: The application can use the cache driver to track maintenance status across multiple servers.
2. Session Management: Session drivers can be configured to use cache-driven backends like redis, memcached, or dynamodb.
3. Testing Environment: In the testing environment, the CACHE_STORE is forced to array to ensure tests are fast and isolated.

Sources: config/app.php:130-134, config/session.php:104-114, phpunit.xml:43

Conclusion

The Caching System provides a flexible and scalable way to manage application performance. By abstracting the storage logic into drivers, it allows developers to switch from local file-based caching during development to distributed systems like Redis in production without changing application code. Its integration with migrations for database storage and its usage in maintenance mode and testing highlights its role as a core utility within the project.

Sources: config/cache.php:3-14, README.md:12-25