Cache-Aside and CQRS Pattern: The Read-Side Architecture for Production Microservices (2026)

Q: What is the difference between cache-aside and CQRS?

Cache-aside and CQRS solve different problems on the read side. Cache-aside is a tactical pattern for accelerating hot reads — on a query, look up the cache; on a miss, query the source of truth, populate the cache with a TTL, and return; on a write, explicitly invalidate the affected keys. The cache is always derivative, never the source of truth. CQRS (Command Query Responsibility Segregation) is a structural pattern that separates the model used for writes (typically normalised, transactional) from the model used for reads (typically denormalised, eventually consistent, shaped for query patterns). The two models are connected by a projector that consumes the write event stream. Used together, CQRS gives you a read model shaped for fast queries; cache-aside accelerates the hottest of those queries further. They are complementary: most production read-heavy systems eventually adopt both.

Q: Why is TTL-only cache invalidation a problem?

TTL-only invalidation means stale data is served for the full TTL after every write. If you set TTL to 5 minutes, then for up to 5 minutes after any write the cache returns the old value. Users see stale reads for that window; if you set TTL low enough to make this acceptable (say 10 seconds), the cache hit rate collapses because most reads now miss. The structural fix is explicit invalidation on write — the cache key is deleted (or updated, or version-bumped) as part of the write path or as a downstream consumer of the event stream — and TTL is the defence in depth that bounds staleness if invalidation is missed for any reason. The right framing is "TTL is how long stale data can persist when everything else fails," not "TTL is the primary freshness mechanism."

Q: What is a cache stampede and how do you prevent it?

A cache stampede happens when a popular cache key expires and hundreds of concurrent requests all miss simultaneously, all query the database, all try to populate the cache. The database is overwhelmed by the simultaneous load; latency spikes propagate upstream; sometimes the database fails entirely. Two production techniques prevent stampedes. (1) Single-flight (also called request coalescing or thundering-herd protection): an in-process lock ensures only one request loads a missed key while concurrent requests wait for the result. (2) Probabilistic early expiration: each request decides probabilistically whether to refresh the cache slightly before TTL expiry, spreading the refresh load across a window so the cache is never simultaneously expired for all readers. Without one of these, every popular key becomes a periodic incident. Most production cache libraries (Caffeine, hot-cache, Go ristretto) support single-flight; probabilistic early expiration is a few lines of application code.

Q: How does CQRS handle eventual consistency?

CQRS makes eventual consistency an explicit contract rather than an accidental property. The read model lags the write model by a measurable amount — typically 50 to 500 milliseconds when healthy, occasionally seconds when the projector has backlog. The architecture handles this by: (1) Naming the trade-off in the API contract — clients are told "read-your-writes is not guaranteed unless you use the read-after-write endpoint." (2) Routing endpoints that need strong consistency (immediate post-write reads in the same session) through the write model directly. (3) Routing endpoints that tolerate eventual consistency (dashboards, search, list views) through the read model. (4) Monitoring projection lag as a first-class SLI with alerts at 5+ seconds sustained. (5) Providing read-model rebuild via event replay as the recovery mechanism when projections corrupt or new fields are needed. The architecture is honest about the trade-off; the API names communicate it; the operational tooling makes lag visible.

Q: Can you have multiple read models in a CQRS system?

Yes — and you usually should. Many teams new to CQRS assume there is one canonical read model, then end up adding awkward joins and indexes to support secondary query patterns until the read model becomes as complex as the write model with worse performance. The right approach is multiple read models, each shaped for a distinct query pattern: a SQL read model for transactional list/detail queries; a search index (Elasticsearch, OpenSearch) for full-text and faceted queries; an OLAP store (ClickHouse, BigQuery) for analytics queries; a key-value cache for hot single-record lookups. Each is projected from the same event stream by its own projector; each scales independently; each can be rebuilt from the events when needed. Building multiple read models is a feature of CQRS, not a complication, when each one demonstrably pays for itself by serving a workload its store is shaped for.

Q: How does the Outbox pattern relate to cache-aside and CQRS?

Outbox is the bridge that makes both patterns reliable. Without Outbox, events emitted from a write transaction are best-effort — they can be lost on crash between the database commit and the broker publish, leaving downstream consumers (the projector, the cache invalidator) permanently behind on those events. With Outbox, events are written to an outbox table inside the same transaction as the business write; a relay process subsequently publishes them to the event bus with at-least-once delivery. The cache invalidator subscribes to the outbox stream and deletes the affected keys when relevant events arrive; the projector subscribes to the same stream and updates the read model. Both consumers see exactly the same event stream in the same order, which guarantees that cache invalidation and read-model projection stay synchronised with the write model. Outbox is what turns "the cache should eventually be invalidated" and "the read model should eventually catch up" from hopeful into guaranteed.

Q: What are the most common cache-aside and CQRS anti-patterns?

Six anti-patterns that defeat both. (1) Cache-as-source-of-truth — writes update the cache and the database is treated as a backup; eventual data loss when the cache fails. (2) TTL-only invalidation — stale data for the full TTL after every write; low TTL kills hit rate. (3) Read-your-own-writes assumed silently — application built on the implicit assumption that the next read sees the new value, with no explicit routing to the write model; intermittent stale reads after user actions, unreproducible bug reports. (4) Projector without idempotency — events redelivered cause duplicate updates (counters double, lists grow); read model drifts permanently from write model. (5) One read model for all queries — defeats the entire point of CQRS by making the read model as complex as the write model; build multiple shaped read models instead. (6) No projection lag monitoring — read model lag is invisible until users complain; treat projection lag as a first-class SLI with alerts at 5+ seconds sustained.

Q: When should you NOT use cache-aside or CQRS?

Three scenarios where the patterns are wrong. (1) Low-volume systems — if your read traffic is comfortably handled by the write database (single-digit RPS, P99 well below SLO), neither pattern pays for itself; the operational cost (more moving parts, more failure modes) exceeds the benefit. Add them when there is a measured need, not preemptively. (2) Strong-consistency requirements across all reads — financial ledgers, inventory in oversold-prone categories, regulatory disclosures cannot tolerate any stale reads; CQRS with eventual consistency is structurally wrong; use the write model directly with read replicas and synchronous replication, or scale the primary. Cache-aside is also risky here; if used, invalidation must be synchronous within the write transaction. (3) Unstable read patterns — if the queries the system serves are constantly changing (early-stage products, exploratory analytics), building specialised read models for each is wasted effort because they will be obsolete by next quarter. Use the write model with judicious indexing until query patterns stabilise.

Q: How do you bootstrap a CQRS read model for an existing service?

Three-phase migration that minimises risk. (1) Add the outbox to the existing write path without changing the read path — every write produces events, but the read API still queries the write database. This validates the event production and gives you weeks of event history before any read traffic depends on it. (2) Build the projector and the new read model in parallel, replaying historical events to populate it; verify the read model matches the write model on a representative sample of records (parity testing). (3) Migrate read traffic gradually — first non-critical queries (dashboards, internal tools) to validate operational behaviour, then critical queries with feature flags that allow instant rollback to the write model if the projection lags or corrupts. Maintain the ability to rebuild the read model from events for the first months while you discover edge cases in the projector. The whole migration typically takes a quarter for a non-trivial service; rushing it is a common cause of CQRS rollouts that get abandoned.

Q: What configuration values work in production for cache-aside and CQRS?

Field-tested defaults. Cache TTLs: 5-15 minutes for hot keys with explicit invalidation; 1-6 hours for warm keys; 30-60 seconds for negative caching (cached absences). Single-flight lock TTL just longer than the typical database load query (2-5 seconds). Probabilistic early refresh in the last 10% of the TTL window. Cache hit rate target ≥ 90% on hot keys — below this, the cache is not earning its complexity. Projection lag SLO of P99 < 1 second with alert at 5+ seconds sustained. Event retention 7-30 days minimum, longer if read-model rebuild from old events is operationally important. Outbox poll interval 50-200 ms (trades latency for database load). Read-model parity testing in CI on a representative sample. These values are starting points; tune based on your write rate, read rate, and consistency requirements, but do not deviate without measurement.

Satyam Kumar

Back to Blog

ai-architecture

The Cache-Aside and CQRS Pattern: Building the Read Side of Production Microservices Without Eventual-Consistency Disasters (2026)

By Satyam KumarApril 23, 202620 min read

cache-aside cqrs command query responsibility segregation read model eventual consistency cache invalidation cache stampede single-flight projection event sourcing outbox pattern redis microservices data patterns distributed systems system design

The Cache-Aside and CQRS Pattern: Building the Read Side of Production Microservices Without Eventual-Consistency Disasters (2026)

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

The Cache-Aside and CQRS Pattern: Building the Read Side of Production Microservices Without Eventual-Consistency Disasters (2026)

Frequently Asked Questions

Share this article

Comments

Leave a comment