A team builds three different read models (a SQL table for a dashboard, an Elasticsearch index for search, a Redis hash for a single-item lookup) all fed from the same stream of domain events. What problem does this design solve, and what new problems does it introduce?

## How the mechanism works The mechanism here is straightforward in principle: the write side emits a single, ordered stream of domain events (e.g. `ProductCreated`, `PriceChanged`, `ProductDiscontinued`) to something like Kafka, an event store, or a transactional outbox, and each read model is maintained by its own independent **projector** — a consumer that subscribes to that stream, applies the events relevant to it, and writes the result into whatever storage technology suits its query pattern. | The projector | What it builds | |---|---| | An Elasticsearch-backed projector | An inverted index for full-text search and faceted filtering. | | A relational projector | Normalized-enough materialized views and pre-joined tables for a reporting dashboard that needs SQL aggregation. | | A Redis-backed projector | Flat hashes keyed by product ID for sub-millisecond single-item lookups on a product detail page. | All three consume the same events, but independently, at their own pace, using their own schema. ## What the design buys you This is a deliberate application of **polyglot persistence**: no single storage technology is good at everything, so rather than compromising and picking one database that's 'okay' at search, 'okay' at reporting, and 'okay' at key lookups, the team gets a store that's genuinely good at each job. It also isolates failure and scaling: - if the search cluster falls over, the product-detail page (served from Redis) keeps working - if the dashboard's reporting queries are heavy and slow, they don't compete for the same database connections or cache memory as the customer-facing lookup path Each projection can also be scaled, tuned, and even redesigned independently — reindexing search doesn't require touching the Redis schema. ## What it costs The trade-offs are real and compound with each additional read model. - **Operationally**, the team now runs, monitors, backs up, and versions N different storage technologies instead of one, each with its own failure modes, upgrade cadence, and on-call runbook. - **More subtly**, the projectors are independent consumers of the same stream, but nothing guarantees they process events at the same rate — Elasticsearch indexing is typically slower than a Redis `SET`, so at any given moment the search index can be meaningfully further behind the write model than the Redis cache is. - That means the read models don't just individually lag the write model (ordinary eventual consistency); they can disagree with each other. A consumer that reads from two read models in the same request — say, showing search results (from Elasticsearch) annotated with 'in stock' badges pulled live from Redis — can present an internally inconsistent view: a product that Elasticsearch still shows as available because its projector hasn't caught up to a `DiscontinueProduct` event, badge-annotated as 'in stock' because Redis has already processed it, or vice versa. ## Failure modes Failure modes concentrate around lag divergence and rebuild cost. 1. **Lag divergence.** If one projector has a bug — say, a schema change on the write side adds a new event type the Elasticsearch projector doesn't know how to handle and it starts throwing and retrying — that one read model quietly falls further and further behind while the others keep pace, and unless there's per-projector lag monitoring, nobody notices until customers report that search results are stale while everything else looks fine. 2. **Rebuild cost.** Rebuilds get more expensive too: what used to be 'replay the event log to repopulate one table' becomes 'replay the same event log N times, once per read model, potentially at different speeds, and now the team has to reason about which combination of read models is consistent with which combination of others during the rebuild window.' 3. **Idempotency.** Idempotency also has to be solved per projector — consumer group offsets, retries, and rebalances mean each projector needs its own de-duplication or idempotent-apply logic; a bug in one doesn't affect the others, but it does mean the guarantees aren't uniform across read models unless the team enforces the same discipline everywhere. ## Where it bites in practice A concrete version of this scenario: an e-commerce catalog publishes `ProductCreated`, `PriceChanged`, and `ProductDiscontinued` events to a message stream. Three projectors consume it — one builds an Elasticsearch index for the search page, one builds a Redis hash for the product-detail page's fast lookup, one builds a Postgres materialized view for the merchandising team's pricing dashboard. During a flash sale, a burst of `PriceChanged` events arrives; Redis, being simple key overwrites, catches up in milliseconds, while Elasticsearch's bulk-indexing pipeline lags by tens of seconds under the load. For those tens of seconds, a shopper can see the new sale price on the product page (from Redis) but find the product missing from a price-filtered search ('under $20') because the search index still reflects the old price (from the lagging Elasticsearch projector). Neither read model is 'wrong' — both are legitimate, eventually-consistent projections of the same event stream — but the two together tell an inconsistent story, and the team has to decide, consciously, how much of that inconsistency the product is willing to expose to users versus mask with UX (e.g., 'prices may take a moment to update in search').