Overview
The event-driven architecture diagram shows BitzOrcas.Modern’s CAP Outbox pattern. Business data writes and Outbox row records are committed in the same database transaction, ensuring events are never lost. A CAP background poller reads the Outbox table and delivers integration events to subscribers via RabbitMQ.
Key takeaways
- Transactional consistency — business operations and event records share the same transaction, preventing “data written but event lost” scenarios
- CAP background polling — a dedicated thread reads the Outbox table and delivers to RabbitMQ
- Dead letter handling — failed deliveries enter a dead letter queue with retry support
- Decoupled subscribers — consumers register through CAP subscription interfaces, with no direct dependency on publishers
- Search and Reporting modules receive data changes only through events
Related
- Eventing abstractions — integration event definitions
- Eventing — CAP configuration and usage