High-Throughput Caching Strategies: Scaling Redis for Ruby Application APIs

port 26379
sentinel monitor mymaster 127.0.0.1 6379 2 # mymaster, master-ip, master-port, quorum
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

Your Ruby application connects to Sentinel, which then directs it to the current master. The redis-rb gem supports Sentinel:

# config/initializers/redis_sentinel.rb
require 'redis'

SENTINEL_HOSTS = [
  { host: ENV.fetch('SENTINEL_1_HOST', 'localhost'), port: ENV.fetch('SENTINEL_1_PORT', 26379).to_i },
  { host: ENV.fetch('SENTINEL_2_HOST', 'localhost'), port: ENV.fetch('SENTINEL_2_PORT', 26380).to_i }
]

REDIS_SENTINEL_POOL_SIZE = ENV.fetch('REDIS_SENTINEL_POOL_SIZE', 10).to_i

Redis.current = ConnectionPool.new(size: REDIS_SENTINEL_POOL_SIZE, timeout: 5) do
  Redis.new(
    driver: :hiredis, # Recommended for performance
    sentinels: SENTINEL_HOSTS,
    role: 'master', # Specify 'master' or 'replica'
    master_name: 'mymaster' # Matches 'sentinel monitor' name
  )
end

7. Caching Strategies: Cache-Aside, Read-Through, Write-Through

The implementation pattern matters. For high-throughput APIs, the Cache-Aside pattern is common:

• Application checks Redis first.
• If data is found (cache hit), return it.
• If data is not found (cache miss), fetch from the primary data store (e.g., database).
• Store the fetched data in Redis.
• Return the data.

For write operations, consider:

• Write-Through: Write to cache and primary store simultaneously. Ensures cache consistency but adds latency to writes.
• Write-Behind (Write-Back): Write to cache immediately, and asynchronously write to the primary store. Fastest writes, but risk of data loss if cache fails before write-back.
• Cache Invalidation: The hardest part. For Cache-Aside, you typically invalidate the cache entry when the underlying data changes in the primary store. This can be done by explicitly deleting the cache key after a successful database update.

Example Cache-Aside with Invalidation:

class User
  include Redis::Objects # Using redis-objects gem for cleaner syntax

  # Define Redis keys as attributes
  redis_id_field :id
  redis_field :name
  redis_field :email
  redis_field :created_at

  # Use a specific Redis instance if needed, otherwise Redis.current
  # def self.redis
  #   Redis.current
  # end

  def self.find_cached(id)
    cache_key = "user:#{id}"
    # Use Redis.current.with for connection pool
    Redis.current.with do |redis|
      cached_data = redis.hgetall(cache_key)
      unless cached_data.empty?
        puts "Cache hit for user:#{id}"
        return new(id: id, **cached_data) # Assuming redis-objects maps back
      end
    end

    puts "Cache miss for user:#{id}"
    # Fetch from database (simulated)
    db_user = fetch_from_database(id)
    return nil unless db_user

    # Store in Redis using Hash
    Redis.current.with do |redis|
      redis.hmset(cache_key,
                  'name', db_user.name,
                  'email', db_user.email,
                  'created_at', db_user.created_at.to_i)
      # Set an expiration to prevent stale data
      redis.expire(cache_key, 1.hour.to_i)
    end

    db_user
  end

  def update_attributes(attrs)
    # Update database first
    success = update_database(attrs) # Simulate DB update

    if success
      # Invalidate cache on successful DB update
      cache_key = "user:#{self.id}"
      Redis.current.with do |redis|
        redis.del(cache_key)
        puts "Cache invalidated for user:#{self.id}"
      end
      # Optionally, update attributes on the current object instance
      attrs.each { |k, v| send("#{k}=", v) }
    end
    success
  end

  private

  def self.fetch_from_database(id)
    # Simulate fetching from a database
    # In a real app, this would be User.find(id) or similar
    puts "Fetching user #{id} from DB..."
    # Return a dummy object for demonstration
    OpenStruct.new(id: id, name: "User #{id}", email: "user#{id}@example.com", created_at: Time.now)
  end

  def update_database(attrs)
    # Simulate updating the database
    puts "Updating user #{self.id} in DB with #{attrs}..."
    true # Assume success
  end
end

# Usage:
# user = User.find_cached(1)
# user.update_attributes(email: '[email protected]')

8. Monitoring and Tuning

Continuous monitoring is crucial. Use Redis's built-in commands and external tools:

• INFO ALL: Provides comprehensive statistics on memory usage, connected clients, command statistics, persistence, etc. Pay attention to used_memory, mem_fragmentation_ratio, instantaneous_ops_per_sec, and rejected_connections.
• MONITOR: Streams all commands processed by Redis. Useful for debugging but has a performance impact.
• SLOWLOG GET [n]: Retrieves the list of slowest commands. Essential for identifying inefficient queries.
• CLIENT LIST: Shows connected clients.

Tuning Parameters:

• maxmemory: Set a limit to prevent Redis from consuming all system RAM. Combine with an appropriate maxmemory-policy (e.g., allkeys-lru for LRU eviction).
• tcp-backlog: Adjust based on expected connection rates.
• timeout: Client-side connection pool timeout and Redis command timeout.
• Persistence: For a pure cache, you might disable RDB/AOF or configure them minimally to reduce write overhead. If data durability is a concern, tune appendfsync (e.g., everysec is a good balance).

Conclusion

Achieving high-throughput caching with Redis for Ruby APIs involves a multi-faceted approach. It starts with efficient client-side connection management, scales horizontally with Redis Cluster or vertically with Sentinel, and relies on smart data modeling and command usage. Implementing patterns like pipelining and Lua scripting, coupled with diligent monitoring and tuning, will ensure your caching layer can keep pace with demanding application loads.