Event-driven architecture lets an application publish events when things happen, while separate components react asynchronously. This keeps publishers loosely coupled to the features that consume their events. section 21.4
A practical message-queue design can provide:
- Multiple subscribers receiving copies of the same event, such as a database saver and an audit handler. section 21.4
- Independent feature additions, including Elasticsearch indexing, Google Calendar reminders, or audit logging, without changing event-publishing logic. section 21.4
- Independent scaling and zero-downtime deployment, because a new handler can run in its own container while existing containers remain unchanged. section 21.4
- Flexible infrastructure choices: Redis and NATS appear alongside RabbitMQ for routing and persistence, and Kafka for very high message volumes. section 21.5
Adding an audit handler
A to-do web app publishes an event when a user creates an item. The existing save handler stores it in SQL, while a separate audit handler subscribes to the same subject and logs its date and text. The web UI does not wait for either process, so additional subscribers do not change its request latency. section 21.4
# run the audit message handler, keeping the same scale # for the save handler: docker compose -f docker-compose.yml ` -f docker-compose-audit.yml up -d --scale save-handler=3 # check that the audit handler is listening: docker logs todo-list-audit-handler-1 # browse to http:/./localhost:8080 and add some new items # check the audit trail: docker logs todo-list-audit-handler-1
Run the audit handler with Docker Compose, add items through the web UI, and inspect the resulting audit logs. section 21.4
