Event-Driven

Event-driven architecture decouples the thing that produces work from the things that react to it. Axis’s messaging constructs are built for exactly this, with defaults that favour observability. This is a composition sketch grounded in the shipped messaging constructs.

The three primitives

• AtfSqs — point-to-point work queues with a DLQ by default, so a poison message goes somewhere you can inspect it. Attach a consumer with attachConsumer(...).
• AtfSns — pub/sub fan-out: one publish, many subscribers.
• AtfEventBridge — content-based routing over custom buses and rules.

A typical flow

A producer handler publishes to an SNS topic or puts an event on an EventBridge bus. Rules and subscriptions fan the event out to SQS queues, each backed by a worker Lambda (Workers & Cron). The DLQ-by-default posture means each consumer has a failure sink for free, and a DLQ-depth alarm (Observability & Alerting) tells you when something is stuck.

The observability dividend

Because every queue has a DLQ and every alert flows to one topic, an event-driven Axis app is unusually easy to operate: failures accumulate visibly rather than vanishing, and one alarm surfaces them.

Where to go next

• Messaging for the construct details.
• CQRS for a read-model projection built on the same backbone.