# Redis/Valkey + Rate Limiting learnings

# Redis Fundamentals

Redis is an in-memory key-value store that delivers sub-millisecond response times and handles up to 1 million queries per second. Originally a simple key-value store, Redis now supports sets, pub/sub messaging, and atomic transactions.

The single-threaded architecture contributes to Redis speed by avoiding context switching overhead. This design limits scaling for write-heavy workloads but ensures predictable performance.

Redis supports persistence through periodic snapshots of in-memory data to disk, providing durability when needed.

# AWS Redis Offerings

## ElastiCache

Ephemeral Redis implementation where data is lost if the server crashes. Fast and cost-effective for pure caching scenarios.

## MemoryDB

Durable Redis implementation that persists data and survives server crashes. Provides Redis performance with database-level durability.

## Valkey

AWS's fork of Redis offering improved performance, cost-effectiveness, and scalability. Maintains full Redis API compatibility while enhancing speed and operational efficiency. Available in serverless mode for automatic scaling.

**Key differences:**

* Valkey: 20-30% better performance than Redis
    
* Full API compatibility for drop-in replacement
    
* Serverless scaling eliminates manual management
    

# Redis Scaling Strategies

## Sharding

Divides data across multiple instances, enabling systems to handle larger datasets than single instances support. Queries route to appropriate shards based on key ranges.

## Replication

Implements master-replica architecture where writes go to master and reads can use replicas. Supports both consistent and eventually consistent reads with minimal replication lag (microseconds).

**Valkey Serverless** combines both strategies, automatically scaling read replicas and shards as needed.

# Rate Limiting Implementation

Rate limiting uses a sliding window algorithm with core logic:

1. Store timestamps in an array for each request
    
2. Count requests within defined time window
    
3. Automatically remove outdated timestamps
    

Keys auto-expire after the time window to prevent memory growth. Real-world usage shows Redis memory fluctuating around 1 GB with effective management.

## Sliding Window Pattern

```json
Key: user_123_rate_limit
Value: [timestamp1, timestamp2, timestamp3...]
TTL: 3600 seconds (1 hour)
```

System checks request count within window, adds new timestamp if under limit, removes expired entries automatically.

# Performance Characteristics

## Redis Performance

* **Throughput**: Up to 1 million QPS per instance
    
* **Latency**: Sub-millisecond response times
    
* **Memory**: Efficient in-memory storage with persistence options
    

## Valkey Improvements

* **Cost**: 20-30% cheaper than Redis
    
* **Performance**: Better throughput and lower latency
    
* **Scaling**: Automatic serverless scaling
    
* **Compatibility**: Drop-in Redis replacement
    

## Rate Limiting Performance

* **Memory Usage**: ~1 GB for production workloads
    
* **Efficiency**: Automatic cleanup prevents memory leaks
    
* **Scalability**: Handles high-volume request patterns
    

# Production Considerations

## Memory Management

* TTL prevents memory leaks in serverless environments
    
* Automatic cleanup maintains performance at scale
    
* Monitor memory usage patterns for optimization
    

## Monitoring

* Track request patterns and rate limit hits
    
* Monitor Redis/Valkey memory usage
    
* Set up alerts for performance thresholds
    

## Scaling

* Start with single instance for most use cases
    
* Add sharding when dataset exceeds single instance
    
* Use replication for read-heavy workloads
    
* Consider Valkey serverless for variable traffic