Implement CQRS Architecture

Diagrams the CQRS architecture splitting a client's writes and reads into separate Commands and Queries APIs, each with its own handlers, where command handlers write to a write model that emits events to update a separate read model, and defines six components: Command as the intent to change state, Command Handler validating and executing it, Event as the record of the change, Query as a data request, Query Handler retrieving from the read model, and Projector updating the read model from events. Ships five templates: command infrastructure (a Command dataclass base auto-generating a command_id and timestamp, concrete commands like CreateOrder, AddOrderItem, and CancelOrder, a generic CommandHandler abstract base, a CommandBus that registers handlers by command type and dispatches to them, and a CreateOrderHandler implementation that validates the command, creates an Order aggregate, and persists its uncommitted events to an event store under a stream ID), query infrastructure (a parallel Query base, concrete queries, typed query results, a QueryHandler base, and a QueryBus), a FastAPI CQRS application (request and response models, dependency injection, POST, PUT, and DELETE command endpoints, and GET query endpoints), read model synchronization, and eventual consistency handling (a ConsistentQueryHandler implementing read-your-writes consistency by polling a projection_state table for the last-processed event version against an expected_version, retrying every 100ms until it catches up or a timeout elapses, at which point it returns the possibly-stale data with an explicit _warning field reading 'Data may be stale' rather than silently returning it as fresh).

Use it when separating command and query paths in an application, building a command or query bus, wiring a FastAPI CQRS API, synchronizing a read model from events, or handling eventual consistency between write and read models. Skip it for anything unrelated to CQRS implementation or outside this scope.

Input is a use case requiring separated write and read paths - an order-processing system, an event-sourced aggregate, or an API needing independently-scaled reads and writes; output is the matching command or query class, handler, bus registration, or FastAPI endpoint, following the documented CQRS component responsibilities.

Framework-agnostic command and query bus infrastructure in plain Python (dataclasses, ABCs, generics) with a FastAPI-specific template for exposing commands and queries as REST endpoints. Assumes an event store as a pluggable dependency for persisting command-generated events.

Backend engineers implementing CQRS who need concrete command bus, query bus, and read-model synchronization code rather than an abstract explanation of separating reads from writes.