Cache

Overview

Temporary data store, typically in RAM, that holds frequently accessed data for faster retrieval.

Core Concepts

• Cache Operations
  • Cache Lookup: Application checks the cache for requested data
  • Cache Hit: Data is found in the cache and returned directly
  • Cache Miss: Data is not found in the cache. The application fetches it from the primary source, updates the cache, and returns the data

Benefits

• Reduced database load
• Faster data access (commonly retrieval from RAM)
• Scalability
• Cost-Effectiveness

Operations

• GET: Retrieve the value of a key
• PUT: Create a new key-value pair or update an existing key
• DELETE: Delete a key-value pair

Key-Value Mappings

Keys

• Unique identifier
• Can be only a string

Values

Redis Data Structures	Underlying Implementation
String	SDS (Simple Dynamic String)
Lists	Bi-Directional LinkedList → QuickList in Redis 7 - O(n) ZipList → ListPack in Redis 7 - O(n)
Hashes	ZipList → ListPack in Redis 7 - O(n) HashTable O(1)
Sets	HashTable O(1) IntSet O(n)
Sorted Sets	ZipList → ListPack in Redis 7 - O(n) SkipList O(log(n))

Persistence

Levels

• 1ns (L1 cache)
• 10ns (L2 cache)
• 100ns (RAM access): Redis read
• 10µs (send data over network): Memcached send data over 1 Gbps network
• 100µs (read from SSD): RocksDB read
• 1ms (database insert): PostgreSQL insert
• 10ms (HDD disk seek): PostgreSQL read
• 100ms (packet CA → NL → CA): Remote Zoom call
• 10s (retry/refresh interval): Grafana refresh interval

Options:

• AOF (Append Only File): Acts like a log, continuously recording every write operation. This allows replaying them on restart to rebuild the data
• RDB (Redis Database): Creates point-in-time snapshots of your entire dataset at regular intervals
• No Persistence: Disables data persistence entirely, suitable for caching temporary data

Eviction Policies

Eviction Policy	Description	Pros	Cons	Use Cases
Least Frequently Used (LFU)	Evicts the least frequently accessed items from the cache. It counts how often an item is accessed	Ideal for scenarios where access frequency varies widely Ensures that frequently accessed items stay in the cache	Complexity in implementation due to the need for tracking access frequency Can be less effective in scenarios with sudden spikes in access frequency	Caching of user profiles, session data, and user preferences
Least Recently Used (LRU)	Evicts the least recently accessed items from the cache. It tracks the time of the last access for each item	Effective in scenarios where recently accessed items are more likely to be accessed again	May not be optimal for scenarios with varying access patterns Requires frequent updates to access timestamps	Web page caching, API response caching, and frequently accessed database records
Size-Based	Evicts items based on the size of the cache. It ensures that the cache does not exceed a predefined size limit	Guarantees that the cache size remains within predefined limits	May lead to eviction of useful items if not carefully tuned May not consider access patterns, leading to suboptimal cache utilization	Image caching, file caching, and multimedia content caching
Time-to-Live (TTL)	Evicts items based on their time since creation or last access. Items are evicted once their predefined lifespan expires	Provides control over the freshness of cached data Useful for scenarios where data validity is time-bound	May lead to eviction of frequently accessed but still valid items Requires careful consideration of TTL values to balance between freshness and cache utilization	News articles, stock prices, and time-sensitive data feeds

Invalidation Strategies

• Time-Based
  • Absolute Timeout: Cached data is invalidated after a fixed period from the time of caching
  • Relative Timeout: Cached data is invalidated after a fixed period from the time of last access or update
  • Sliding Timeout: Timeout period is extended every time the data is accessed or updated
• Event-Based Invalidation
  • Publish/Subscribe Model: Invalidate cache based on events published by the data source or other relevant services
  • Webhooks: Trigger cache invalidation based on HTTP callbacks from the data source
  • Message Queue Integration: Invalidate cache in response to messages received from a message queue
• Manual Invalidation
  • Programmatic Invalidation: Invalidate cache entries programmatically through API calls or direct cache manipulation
  • Admin Console: Provide a user interface for administrators to manually invalidate cache entries

Redis vs Memcached

Aspect	Redis	Memcached
Data Structure	List Set/Sorted Set Hash Bit Array HyperLogLog	Plain string value
Architecture	Single-thread for read/write keys	Multi-threaded
Transactions	Support atomic operations	❌
Snapshots/Persistence	Keep data on disks Support RDB/AOF persistence	❌
Pub-Sub Messaging	Support Pub-Sub messaging with pattern matching	❌
Geo-Spatial Support	Geospatial indexes that stores the longitude and latitude data of the location	❌
Server-Side Script	Support Lua script to perform operations inside Redis	❌
Support Cache Eviction	noeviction allkeys-lru/allkeys-lfu/allkeys-random volatile-lru/volatile-lfu/volatile-random/volatile-ttl	LRU
Replication	Leader-Follower replication	❌

Security

Overview

Cache Miss

Cache Miss Attack exploits weaknesses in how data is stored to steal information or overload systems. It targets situations where a web application doesn't consider all input data when storing data in a cache. This lets attackers trick the cache into revealing sensitive information or causing performance issues.

Solutions:

• Cache keys with null value. Set a short TTL (Time to Live) for keys with null value
• Bloom filter to quickly check if key exists before hitting cache/database