Sizing and Capacity Planning

This guide helps you estimate memory requirements, plan for growth, and understand when to scale your Swytch deployment.

Every key stored in Swytch has fixed overhead beyond the key and value bytes:

Rule of thumb: Each key-value pair uses len(key) + len(value) + 90 bytes of memory.

Total Memory = (num_keys × 90) + total_key_bytes + total_value_bytes

Example: 10 million keys with average 20-byte keys and 200-byte values:

Memory = (10,000,000 × 90) + (10,000,000 × 20) + (10,000,000 × 200)
       = 900MB + 200MB + 2000MB
       = 3.1GB

Add 20% headroom for runtime overhead: ~3.7GB recommended maxmemory

Different Redis data types have additional per-element overhead:

Example: A hash with 100 fields averaging 10-byte names and 50-byte values:

Hash overhead = 100 × (24 + 10 + 50) = 8,400 bytes per hash

Your working set is the subset of data actively accessed within a time window. Swytch keeps all data in memory — when the cache is full, the eviction algorithm removes infrequently accessed keys to make room.

Use these metrics to understand whether your working set fits in memory:

Working set fits in memory when:

• Hit rate is high (>90%)
• Evictions are infrequent
• p99 latency is stable

Working set exceeds memory when:

• Hit rate is dropping
• Consistent eviction pressure
• Frequently accessed keys are being evicted and re-populated

Hit Rate = cache_hits / (cache_hits + cache_misses)

Or use the pre-computed gauge:

swytch_redis_cache_hit_rate

Target: Hit rate > 90% for latency-sensitive workloads.

Use this worksheet to plan your deployment:

Current keys:           ____________
Average key size:       ____________ bytes
Average value size:     ____________ bytes
Growth rate (monthly):  ____________ %

Current data size = keys × (key_size + value_size + 90)
                  = ____________ GB

6-month projection = current × (1 + growth_rate)^6
                   = ____________ GB

Swytch is an in-memory cache. All active data must fit in --maxmemory. When the limit is reached, the eviction algorithm removes infrequently accessed effects automatically.

maxmemory = data_size × 1.2  (20% headroom)

If your total dataset is larger than available memory, Swytch functions as a cache — frequently accessed keys stay in memory while cold keys are evicted. In this case, size for your working set:

maxmemory = working_set_size × 1.2

If unknown, start generous and monitor hit rate.
Reduce gradually until hit rate drops below your target.

container_memory = maxmemory + max(512MB, maxmemory × 0.2)
container_cpu = based on expected ops/sec (see Deployment guide)

The extra memory beyond --maxmemory accounts for connection buffers, Lua scripting overhead, the Go runtime, and cluster replication state (if clustered).

Set up alerts for proactive scaling:

# Prometheus alerting rules
groups:
  - name: swytch-capacity
    rules:
      - alert: SwytchMemoryPressure
        expr: swytch_redis_memory_bytes / swytch_redis_memory_max_bytes > 0.9
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Swytch memory usage above 90%"

      - alert: SwytchHighEvictionRate
        expr: rate(swytch_redis_evictions_total[5m]) > 1000
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "High eviction rate indicates memory pressure"

      - alert: SwytchLowHitRate
        expr: swytch_redis_cache_hit_rate < 0.8
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Cache hit rate below 80%"