Apr 8, 2026 · Written by: Netspare Team

Read Replicas, Query Caches, and Redis: Where to Put the Load

Read replicas spread SELECT load away from the primary database, but replication is asynchronous by default—stale reads are a feature you must design around, not a surprise bug.

Application caches (Redis, Memcached) reduce database pressure further; wrong TTL or cache key design causes subtle data corruption perceptions.

Replication lag and user-visible consistency

After a user writes a profile change, reading from a lagging replica may show old data—route session-critical reads to primary or use read-your-writes tokens.

Monitor `Seconds_Behind_Master` or PostgreSQL replication lag metrics; alert before lag crosses product SLAs.

Cache invalidation strategies

Time-based TTL is simplest but either serves stale data too long or thrashes the DB on short TTL.

Event-driven invalidation (delete key on write) needs discipline so every code path updates caches consistently.

Anti-patterns to avoid

Caching entire HTML pages for logged-in users without user-specific keys.
Using replicas for financial balance reads without verifying tolerance.
Stampeding: many workers miss cache simultaneously and hammer the DB—use jitter or single-flight.

Measure before adding layers

EXPLAIN ANALYZE slow queries first; a missing index beats a new Redis cluster in cost and complexity.

Track cache hit ratio and p95 query time together—optimizing one while ignoring the other misleads capacity plans.

Frequently asked questions

Can I use a replica for backups?

Logical or filesystem backups from replicas are common, but verify consistency requirements; long-running backups can amplify lag.

Redis down—what happens?

Circuit-break to database with rate limits or degrade features; design fallback paths in advance.

Netspare Team