Event Overview
The system publishes three main types of internal events:- ProductSoldInternalEvent - Published when a product is sold
- ProductCreatedInternalEvent - Published when a new product is created
- AlertInternalEvent - Published when suspicious activity is detected
ProductSoldInternalEvent
Published by the Orders service when a product sale transaction is completed. This event is consumed by the Sentinel service for fraud detection and monitoring.Event Schema
Fields
The unique identifier of the product that was sold
The number of units sold in the transaction
The client IP address from which the purchase was made. Used for fraud detection and geographic analysis.
The exact date and time when the sale occurred in ISO-8601 format
Message Configuration
argos.sales.queueshop.exchange (Topic Exchange)shop.event.soldEvent Example
Event Flow
The Orders service uses the
shop.exchange Topic Exchange to allow multiple consumers to process sale events independently.ProductCreatedInternalEvent
Published by the Orders service when a new product is successfully created in the system.Event Schema
Fields
The complete product information including the newly generated ID
Message Configuration
argos.products.mgmt.queueshop.exchange (Topic Exchange)shop.event.product.# (wildcard pattern)Event Example
The routing key uses a wildcard pattern (
shop.event.product.#) to allow for future product-related events such as shop.event.product.updated or shop.event.product.deleted.AlertInternalEvent
Published by the Sentinel service when suspicious activity or security threats are detected, such as DDoS attacks or unusual purchasing patterns.Event Schema
Fields
The type of alert detected. Common values:
DDoS AttackSuspicious Purchase PatternRate Limit ExceededInventory Manipulation
The IP address associated with the suspicious activity (e.g.,
127.0.0.1, 192.168.1.100)The severity level of the alert:
CRITICAL- Immediate action requiredHIGH- Requires urgent attentionMEDIUM- Should be investigatedLOW- Informational
When the alert was generated in ISO-8601 format
Message Configuration
argos.alert.queuealert.exchange (Topic Exchange)argos.alert.# (wildcard pattern)Event Example
Consumers
TheAlertInternalEvent is consumed by:
- Notify Service - Sends notifications to administrators via email, SMS, or other channels
- Security Dashboard - Updates real-time monitoring displays
- Logging System - Archives alerts for compliance and audit purposes
RabbitMQ Configuration
Exchanges
The system uses two main Topic Exchanges:| Exchange Name | Purpose |
|---|---|
shop.exchange | Product and sales events |
alert.exchange | Security and monitoring alerts |
Queues
| Queue Name | Bound To | Routing Key | Consumer |
|---|---|---|---|
argos.sales.queue | shop.exchange | shop.event.sold | Sentinel Service |
argos.products.mgmt.queue | shop.exchange | shop.event.product.# | Product Management |
argos.alert.queue | alert.exchange | argos.alert.# | Notify Service |
Message Serialization
All events are serialized as JSON using Jackson with the following configuration:The
JavaTimeModule ensures that LocalDateTime fields are serialized as ISO-8601 strings rather than timestamps.Event Publishing
From Orders Service
The Orders service publishes events using Spring AMQP:From Sentinel Service
The Sentinel service publishes alerts:Event Consumption
Listening to Sales Events
Listening to Alert Events
Best Practices
Event Idempotency
Event Idempotency
Consumers should be designed to handle duplicate events gracefully. Use unique transaction IDs or timestamps to detect and skip duplicate processing.
Error Handling
Error Handling
Implement dead letter queues (DLQs) for messages that fail processing. Configure retry policies with exponential backoff.
Monitoring
Monitoring
Monitor queue depths, message rates, and consumer lag to ensure healthy event processing. Set up alerts for queue buildup.
Schema Evolution
Schema Evolution
When modifying event schemas, maintain backward compatibility. Add new optional fields rather than modifying existing ones.
Troubleshooting
Messages Not Being Consumed
- Verify the queue exists and is bound to the correct exchange
- Check the routing key matches the binding pattern
- Ensure the consumer service is running and connected to RabbitMQ
- Review consumer logs for exceptions
High Queue Depth
- Check if consumers are processing messages slowly
- Scale up the number of consumer instances
- Investigate if messages are being rejected and requeued
- Review message sizes and processing complexity