Centralized Cache Configuration
The CQL library provides a comprehensive, centralized cache configuration system that allows you to configure all caching functionality from one place. This approach follows SOLID principles and provides a clean, maintainable way to manage cache settings across your entire application.
Overview
Instead of configuring cache settings in multiple places across your application, CQL's centralized configuration allows you to:
Configure all cache settings in one place
Apply environment-specific defaults automatically
Validate configuration at startup
Access cache functionality through a unified API
Monitor and manage cache performance centrally
Basic Configuration
require "cql"
CQL.configure do |config|
config.database_url = "postgresql://localhost/myapp"
# Enable caching with basic settings
config.cache.enabled = true
config.cache.default_ttl = 30.minutes
config.cache.key_prefix = "myapp"
endCache Configuration Options
The cache configuration is accessed through config.cache and provides the following options:
Core Settings
enabled
Bool
false
Enable or disable the entire cache system
default_ttl
Time::Span
1.hour
Default time-to-live for cache entries
key_prefix
String
"cql"
Prefix for all cache keys
cache_name
String
"cql"
Name for the cache instance
Memory Cache Settings
enable_memory_cache
Bool
true
Enable in-memory caching
memory_cache_max_size
Int32?
1000
Maximum number of entries in memory cache
memory_cache_enable_statistics
Bool
true
Enable statistics collection for memory cache
Request-Scoped Cache Settings
enable_request_cache
Bool
true
Enable per-request query caching
request_cache_max_size
Int32
1000
Maximum entries per request
auto_clear_request_cache
Bool
true
Automatically clear cache between requests
Fragment Cache Settings
enable_fragment_cache
Bool
false
Enable fragment caching
fragment_cache_enable_versioning
Bool
true
Enable version-based invalidation
fragment_cache_enable_tagging
Bool
true
Enable tag-based invalidation
Invalidation Strategy Settings
invalidation_strategy
String
"timestamp"
Strategy for cache invalidation ("timestamp", "version", "transaction_aware")
max_cache_age
Time::Span
1.hour
Maximum age for timestamp-based invalidation
Performance and Monitoring
enable_cache_statistics
Bool
true
Enable cache performance statistics
enable_cache_logging
Bool
false
Enable cache operation logging
cache_log_level
Log::Severity
Debug
Log level for cache operations
Advanced Settings
auto_cleanup_expired
Bool
true
Automatically clean up expired entries
cleanup_interval
Time::Span
5.minutes
Interval for cleanup operations
enable_batch_operations
Bool
true
Enable batch cache operations
Middleware Integration
enable_middleware_integration
Bool
false
Enable automatic middleware integration
middleware_request_id_header
String
"X-Request-ID"
Header name for request ID tracking
Environment-Specific Defaults
The cache configuration automatically applies environment-specific defaults:
Development Environment
enabled = trueenable_cache_logging = truecache_log_level = Debugmemory_cache_max_size = 1000request_cache_max_size = 1000
Test Environment
enabled = false(disabled by default for test isolation)enable_cache_logging = falsememory_cache_max_size = 100request_cache_max_size = 100
Production Environment
enabled = false(disabled by default for safety)enable_cache_logging = falsecache_log_level = Infomemory_cache_max_size = 5000request_cache_max_size = 2000
Comprehensive Configuration Example
Cache Management API
Once configured, you can manage the cache system through the CQL module:
Enable/Disable Cache
Statistics and Monitoring
Request-Scoped Caching
Create Cache Instances
Web Framework Integration
The centralized configuration works seamlessly with web framework middleware:
Kemal
Lucky
Configuration Validation
The configuration system includes comprehensive validation:
Best Practices
Environment-Specific Configuration: Override defaults for production environments
Memory Limits: Set appropriate
memory_cache_max_sizebased on available memoryTTL Settings: Configure
default_ttlbased on your data freshness requirementsRequest Caching: Enable for web applications to eliminate duplicate queries
Fragment Caching: Use for expensive computations or complex query results
Monitoring: Enable statistics in development but consider disabling logging in production
Invalidation Strategy: Choose the strategy that best fits your data consistency needs
Production Configuration Example
This centralized approach provides a clean, maintainable way to configure all caching functionality while ensuring optimal performance and proper resource management across different environments.
Last updated
Was this helpful?