Redis Caching Strategies for High-Read SaaS APIs in Go

Redis caching is one of the highest return-on-investment infrastructure changes you can make to a Go SaaS backend. A well-designed caching layer reduces database load by 60 to 80%, cuts API response times from 80ms to under 10ms for read-heavy endpoints, and lets you scale read traffic without adding database replicas.

But Redis is not a simple key-value bolt-on. Getting caching right in a multi-tenant SaaS product requires careful key design, precise invalidation logic, and defensive coding for the scenarios that only appear at scale. This is the caching approach we use for Go backends serving SaaS products in Lebanon and MENA.

When to add Redis to a Go SaaS backend

Not every Go service needs Redis. Adding caching too early increases operational complexity without proportional benefit. The right time to add Redis is when you have a measurable problem: database query time is dominating API response time, read queries are a large fraction of total database load, or the same data is being fetched repeatedly within short time windows.

Some use cases that reliably benefit from Redis caching in SaaS backends:

User and organization data. Most SaaS requests authenticate against a user record and check organization permissions. These records change infrequently but are fetched on every request. Caching them reduces authentication overhead from a database roundtrip to a sub-millisecond cache read.

Feature flag and configuration data. Feature flags, plan limits, and configuration values are read frequently and change rarely. A five-minute cache TTL on these values eliminates most of the database read load they generate.

Aggregation query results. Dashboard queries that summarize activity over time windows are expensive to compute. Caching the result with a TTL that matches the acceptable staleness is the correct approach.

List queries with heavy joins. Endpoints that return paginated lists with multiple joins can take 50 to 200ms at scale. Caching the first few pages with a short TTL reduces latency significantly without requiring schema changes.

Cache-aside vs write-through: which one for SaaS

The two main patterns for integrating Redis into a SaaS read path are cache-aside (lazy loading) and write-through (eager loading).

Cache-aside is the standard pattern for SaaS backends. The application reads from Redis first. On a miss, it reads from the database, stores the result in Redis, and returns it to the caller. On a write, the application updates the database and deletes or updates the cache entry.

func (r *UserRepo) GetUser(ctx context.Context, userID uuid.UUID) (*User, error) {
    key := fmt.Sprintf("user:%s", userID)
    
    // Try cache first
    cached, err := r.redis.Get(ctx, key).Bytes()
    if err == nil {
        var user User
        if err := json.Unmarshal(cached, &user); err == nil {
            return &user, nil
        }
    }
    
    // Cache miss — load from database
    user, err := r.db.GetUserByID(ctx, userID)
    if err != nil {
        return nil, err
    }
    
    // Store in cache
    data, _ := json.Marshal(user)
    r.redis.Set(ctx, key, data, 5*time.Minute)
    
    return user, nil
}

Write-through keeps the cache always current by writing to both the database and Redis synchronously on every update. This eliminates cache misses after the first load but increases write latency and complexity. For most SaaS use cases, cache-aside is preferable because write-through couples the write path to cache availability, meaning a Redis outage blocks writes.

Multi-tenant key namespacing in Redis

Multi-tenant SaaS products store data for multiple organizations in the same database. The same must be true of the Redis cache. If the cache key for a user's organization data is org:123:config, it works. But if two tenants somehow end up with the same internal ID range, or if a key collision is possible through any other mechanism, one tenant's data could be served to another tenant. This is a data leak.

The defense is explicit tenant namespacing in every cache key.

func orgCacheKey(orgID uuid.UUID, resource string) string {
    return fmt.Sprintf("org:%s:%s", orgID.String(), resource)
}

func userCacheKey(orgID, userID uuid.UUID) string {
    return fmt.Sprintf("org:%s:user:%s", orgID.String(), userID.String())
}

This makes the tenant scope explicit and auditable. When reviewing cache key generation code, you can see immediately whether the tenant ID is always present.

Org-scoped key patterns also make bulk invalidation practical. When an organization changes their plan or their configuration is updated, invalidating all keys with the prefix org:{orgID}: flushes only that tenant's cache. Redis SCAN with a pattern match handles this without blocking the server.

func (c *Cache) InvalidateOrgCache(ctx context.Context, orgID uuid.UUID) error {
    pattern := fmt.Sprintf("org:%s:*", orgID.String())
    var cursor uint64
    for {
        keys, next, err := c.redis.Scan(ctx, cursor, pattern, 100).Result()
        if err != nil {
            return err
        }
        if len(keys) > 0 {
            c.redis.Del(ctx, keys...)
        }
        cursor = next
        if cursor == 0 {
            break
        }
    }
    return nil
}

TTL design: per-entity TTL strategy

Setting the same TTL for every cached value is the wrong approach. TTL should reflect the acceptable staleness of each type of data and the cost of a cache miss.

User profile data. Changes a few times per session at most. TTL of 10 to 30 minutes is reasonable. Invalidate explicitly on update.

Organization configuration. Changes on billing events or admin actions. TTL of 30 minutes to 2 hours. Invalidate explicitly on write.

Feature flags. Changes only on deployment or admin action. TTL of 5 to 10 minutes. Short enough to pick up changes quickly, long enough to provide significant cache benefit.

Aggregation query results (dashboards). Acceptable to be 1 to 5 minutes stale for most metrics. TTL matches the acceptable staleness window.

Search and filter results. These depend on the underlying data that changes frequently. Short TTL of 30 to 60 seconds or explicit invalidation on every write to the relevant tables.

Never use TTL as the only invalidation mechanism for data that changes on explicit user or system actions. Always invalidate on write. TTL is a safety net for the cases where the explicit invalidation was missed.

Cache stampede: the distributed thundering herd

Cache stampede happens when a popular cache entry expires and multiple concurrent requests all miss the cache simultaneously, all go to the database, and all try to populate the cache at the same time. For a query that takes 200ms under normal conditions, 100 concurrent misses suddenly send 100 parallel queries to the database, which can overwhelm the database and cause cascading failures.

The two main defenses are probabilistic early expiry and distributed locking.

Probabilistic early expiry (also called XFetch) refreshes the cache entry slightly before it expires based on a random probability that increases as expiry approaches. This spreads the refresh load over time instead of concentrating it at the expiry moment.

func (c *Cache) GetWithEarlyRefresh(ctx context.Context, key string, fetch func() (interface{}, error), ttl time.Duration) (interface{}, error) {
    result, remaining, err := c.getWithTTL(ctx, key)
    if err == nil {
        // Probabilistic early refresh: refresh with increasing probability as expiry approaches
        fractionRemaining := float64(remaining) / float64(ttl)
        if fractionRemaining > rand.Float64() {
            return result, nil
        }
    }
    
    // Fetch fresh value
    fresh, err := fetch()
    if err != nil {
        return result, nil // serve stale if fetch fails
    }
    
    c.redis.Set(ctx, key, fresh, ttl)
    return fresh, nil
}

The simpler alternative is a distributed lock: the first goroutine to miss the cache acquires a lock, fetches from the database, and populates the cache. Other goroutines wait briefly and then read from the cache after the lock is released. This works but adds latency for the waiters and requires careful lock timeout design.

Circuit breaker: what happens when Redis goes down

Redis unavailability should not take down your API. Cache reads and writes should always be wrapped in error handling that falls through to the database on Redis failure.

func (r *UserRepo) GetUser(ctx context.Context, userID uuid.UUID) (*User, error) {
    key := userCacheKey(userID)
    
    // Attempt cache read, fall through to DB on any error
    if cached, err := r.redis.Get(ctx, key).Bytes(); err == nil {
        var user User
        if err := json.Unmarshal(cached, &user); err == nil {
            return &user, nil
        }
    }
    
    // Database is the source of truth
    user, err := r.db.GetUserByID(ctx, userID)
    if err != nil {
        return nil, err
    }
    
    // Attempt cache write, ignore error if Redis is down
    if data, err := json.Marshal(user); err == nil {
        r.redis.Set(ctx, key, data, 5*time.Minute)
    }
    
    return user, nil
}

For a production system serving MENA businesses, adding a proper circuit breaker around Redis operations prevents an extended Redis outage from repeatedly attempting connections, which adds latency to every request. The sony/gobreaker library provides a clean implementation.

Real numbers: what caching actually buys in production

For a multi-tenant SaaS backend with typical read-heavy patterns, after implementing cache-aside with explicit invalidation on user and organization data:

Authentication overhead drops from 15ms average (database lookup) to under 1ms (Redis lookup) for authenticated requests. On an API with 500 requests per second, this saves 7 seconds of cumulative database time per second of wall time.

Database connection pool utilization drops by 40 to 60% for read-heavy workloads, which means you can delay horizontal database scaling by months.

Dashboard API endpoints that aggregated data over 30-day windows go from 800ms average to 12ms average with a 60-second TTL on the aggregation result.

The infrastructure cost increase from a Redis instance is typically USD 30 to 100 per month. The database scaling you defer as a result often represents 5x to 20x that cost, making Redis one of the clearest positive ROI infrastructure investments available.

Key lessons from production

Always namespace cache keys by tenant ID in multi-tenant SaaS. A key collision between tenants is a data leak.

TTL is a safety net, not the primary invalidation mechanism. Always invalidate on write.

Cache-aside with graceful Redis fallback is the right default for SaaS API caching. Write-through creates write path dependencies on cache availability.

Design for stampede at any endpoint that is frequently accessed and expensive to compute. Probabilistic early refresh is the most operationally simple defense.

Measure cache hit rates per key type. A 40% hit rate means your TTL or invalidation strategy needs work. A 99% hit rate on user records means you are caching effectively.