CQRS

CQRS (Command Query Responsibility Segregation) separates the path that changes state from the path that reads it, so each can be optimised independently. In Axis this is a composition of constructs you already have; there is no dedicated CQRS example, so this is a sketch to adapt.

The write path

Commands land on write handlers (REST or GraphQL routes) that mutate a source-of-truth AtfDynamo table. Enable the table’s stream (NEW_AND_OLD_IMAGES) so every change is emitted as an event.

Propagating changes

A stream consumer — or an AtfEventBridge rule fed from the stream — projects each change into one or more purpose-built read models: a denormalised table optimised for a specific query, a search index, or a cache. Because the projection is asynchronous, read models are eventually consistent, which is the trade CQRS makes deliberately.

The read path

Query handlers read exclusively from the read models, never the write table. Each read model is shaped for its queries, so reads are fast and cheap even when the write model isn’t query-friendly.

A caveat on wiring

Attaching a Lambda target to a rule is a construct-method call today, not a static-config path (a tracked DataStack gap — see Messaging), so the stream→projection wiring lives in a stack subclass or a custom stack.

Where to go next

• DynamoDB Tables for streams and read-model table design.
• Event-Driven for the propagation backbone.