Which categories of managed cloud services are commonly used to implement the event store and the projection pipeline in a CQRS-plus-event-sourcing architecture, and what role does each typically play?

## The four moving pieces CQRS with event sourcing needs four moving pieces working together: 1. somewhere durable to append events in order; 2. a way to deliver those events to interested consumers; 3. compute to run the projection logic; 4. somewhere query-optimized to land the resulting read models. Cloud platforms offer managed services for each piece, and most production implementations assemble the pipeline from these rather than hand-rolling an event store from scratch. ## The durable, ordered log The first piece is the durable, ordered event log itself. This is typically implemented with a managed streaming/pub-sub platform — a hosted Kafka-compatible service, or a cloud-native equivalent — that guarantees events are: - appended in order (usually per-partition or per-entity-stream); - retained durably; - readable by multiple independent consumers at their own pace. The defining property that makes these suitable as an 'event store' is that a consumer's read doesn't remove or alter the data — many projectors can each maintain their own read position ('offset' or 'cursor') into the same stream without interfering with each other. An alternative, increasingly common path is to skip a dedicated event log and instead use a **change-data-capture (CDC)** or 'change feed' feature built into a managed operational database: writes to a normal table or document store are also emitted, in order, as a change stream that downstream projectors can subscribe to. This lets a team get event-driven projections without redesigning the write side around an explicit event-sourcing model — a lighter-weight, more common entry point for many cloud teams than 'full' event sourcing. ## The projector The second piece is the projector — the code that consumes each event and updates a read model. In cloud-native deployments this is very commonly implemented as **serverless, event-triggered compute**: - a function that's automatically invoked per incoming event (or per small batch); - scales its concurrency with event volume; - is billed per invocation rather than for an always-on worker. This fits the projection workload well because event arrival is often bursty, and a function-based projector avoids provisioning a persistent worker fleet sized for peak load. Teams with stricter ordering, stateful-aggregation, or very-high-throughput needs sometimes instead run a dedicated, always-on stream-processing job rather than a per-event function, trading some operational overhead for tighter control over batching, state, and ordering guarantees. ## The read-model store The third piece is the read-model store, chosen per consumer's access pattern rather than uniformly. | Managed read store | Access pattern | |---|---| | A document database | suits a UI that needs to fetch a whole denormalized 'order summary' object by ID in one round trip | | A managed search service | suits full-text or faceted queries a document store handles poorly | | A key-value/cache service | suits ultra-low-latency point lookups on a hot path | | A managed data warehouse | suits heavy aggregation and reporting queries across many events | Because CQRS decouples the read side from the write side's schema entirely, nothing forces all projections onto the same storage technology — and in practice they usually aren't, precisely because each is optimized for a different query shape. ## Why this matters for a cloud team Why this matters for a cloud team specifically: assembling the pipeline from managed services shifts a large amount of operational burden — durability, replication, scaling the log itself, patching brokers — onto the cloud provider, leaving the team responsible mainly for projector logic and read-store schema design. The tradeoff is **cost model and lock-in**: managed streaming/CDC/serverless services bill on throughput, invocation count, and storage retention, which can get expensive at very high event volumes, and moving off a specific provider's event-store or CDC implementation later is nontrivial work. ## Failure modes Failure modes specific to this managed-service composition include: - CDC feeds silently dropping or reordering events during a source database failover if the feature's ordering/delivery guarantees aren't well understood; - serverless projector functions timing out or throttling under a sudden event burst, causing lag spikes; - retention limits on the underlying log meaning that if a projection falls behind for too long, the events it needs may have already expired and can no longer be replayed from that log, requiring a longer-retention archive tier for full rebuildability. ## Where it shows up A concrete real-world shape: a retail order system uses a managed database's native change feed to emit order-table writes as an ordered event stream, a set of serverless functions subscribed to that feed to update a 'current order status' document store for the customer app and a separate search-indexed store for internal support-agent lookups, with the change feed's extended retention tier kept available so either projection can be fully rebuilt from scratch if its logic changes.