Exactly-Once, CQRS, and Event Sourcing Replay on AWS
Quick summary: Exactly-once is a myth end to end, but idempotent consumers plus event stores get you close. CQRS read models on DynamoDB streams, Kinesis, and EventBridge replay semantics.
Key Takeaways
- CQRS read models on DynamoDB streams, Kinesis, and EventBridge replay semantics
- As of June 2026, AWS messaging is at-least-once unless you engineer Kafka EOS or FIFO dedup, and your database write must still be idempotent
- Implement idempotent writes on DynamoDB and treat Kinesis as at-least-once
- Layers of exactly-once 1
- Broker: Kafka transactions / SQS FIFO dedup ID 2
Table of Contents
As of June 2026, AWS messaging is at-least-once unless you engineer Kafka EOS or FIFO dedup, and your database write must still be idempotent.
Symptoms, mechanisms, and AWS controls
| Production symptom | Mechanism | AWS control |
|---|---|---|
| Duplicate charges on retry | At-least-once delivery without idempotency | DynamoDB idempotency keys, SQS FIFO deduplication |
| Stale read model after replay | Projection lag during catch-up | Kinesis enhanced fan-out, dedicated projection workers |
| Unbounded event store growth | Append-only without compaction | DynamoDB TTL on snapshots, S3 archival via Firehose |
My recommendation: treat exactly-once as a consumer contract. Implement idempotent writes on DynamoDB and treat Kinesis as at-least-once.
Benchmark pattern (hypothetical workload): order service with CQRS on DynamoDB + Kinesis, 8K events/sec, idempotent consumer dedup via conditional writes reduces duplicate side-effects from 1.2% to 0.001%, replay of 72-hour window completes in 47 minutes on 12 Lambda parallel consumers.
Layers of exactly-once
- Broker: Kafka transactions / SQS FIFO dedup ID
- Consumer: idempotency key store (DynamoDB)
- Projection: CQRS read model version column
CQRS + event sourcing on AWS
| Piece | Service |
|---|---|
| Event log | Kinesis / MSK / EventBridge archive |
| Command side | Lambda + Aurora |
| Read model | DynamoDB / OpenSearch |
| Replay | New consumer group / replay archive to SQS |
Replay strategies: rebuild the read model from offset 0, and use version vectors or optimistic locking on projections.
AWS services map
| Need | Service | Skip when |
|---|---|---|
| Durable event log | Kinesis Data Streams | Simple CRUD with PostgreSQL |
| Idempotent side-effects | DynamoDB conditional writes | Fire-and-forget SNS notifications |
| Read model rebuild | Lambda + DynamoDB GSI projections | Single-table OLTP with no projections |
What to do this week
- Add
event_idunique constraint on projection table. - Test replay in staging and measure duplicate suppression.
- Read microservices patterns guide for outbox.
More in this track
Part of the Engineering Guides library (June 2026).
- Previous: Part 4
- Next: Part 6
- Browse tracks: Engineering Guides hub
What this guide doesn’t cover
Saga orchestration is covered in the canonical microservices post.
Frequently asked questions
Does Kinesis or EventBridge give me exactly-once end to end?
When should I skip CQRS and event sourcing?
What could go wrong if I replay without an event_id unique key?
How do I keep an append-only store from growing forever?
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
