Overview
The Events Processor is primarily used in Bitwarden cloud deployments. Self-hosted instances typically handle events synchronously.
- Queue Processing: Consume events from Azure Queue Storage
- Azure Service Bus: Distributed event processing
- Event Persistence: Store events in database and Azure Table Storage
- Integration Triggers: Notify external services (Slack, Teams, webhooks)
- Scalability: Process high-volume events asynchronously
- Reliability: Retry failed event processing with exponential backoff
Architecture
Configuration
Fromsrc/EventsProcessor/Startup.cs:19:
Service Configuration
Background Processing
Azure Queue Service
The main event processing loop:Azure Queue Processor
Message Processing
Events are processed and persisted:Event Processing
Service Bus Integrations
Fromsrc/EventsProcessor/Startup.cs:36:
Service Bus Listeners
- Slack Notifications: Real-time event notifications to Slack channels
- Microsoft Teams: Webhook notifications to Teams channels
- Custom Webhooks: User-defined HTTP webhook integrations
Event Integration Flow
1
Event Published
API service publishes event to Service Bus topic
2
Subscription Filtering
Service Bus routes to appropriate subscriptions based on filters
3
Listener Processing
Events Processor listener receives and processes event
4
Integration Delivery
Event forwarded to configured integration (Slack, Teams, webhook)
5
Error Handling
Failed deliveries retried with exponential backoff
Event Storage
Dual Storage Strategy
Events are stored in two locations: SQL Database:- Structured event data
- Relational queries
- Compliance reporting
- Long-term retention
- High-throughput writes
- Cost-effective storage
- Time-range queries
- Scalable event log
Event Persistence
Middleware Pipeline
Fromsrc/EventsProcessor/Startup.cs:40:
Request Pipeline
Health Monitoring
The service exposes health check endpoints:Alive Check
Version Check
Queue Configuration
Azure Queue Storage
Configure via environment variables:- Visibility Timeout: 5 minutes (message processing time)
- Max Dequeue Count: 5 attempts before moving to poison queue
- Batch Size: 32 messages per dequeue operation
- Polling Interval: 5 seconds when queue is empty
Service Bus Topics
Service Bus configuration:- Subscriptions: Multiple listeners per topic
- Filtering: SQL-based message filtering
- Dead-lettering: Failed message handling
- Sessions: Ordered message processing
Event Message Format
Event Queue Message
Integration Webhooks
Slack Integration
Slack webhook format:Slack Message
Microsoft Teams
Teams webhook format (Adaptive Card):Teams Message
Error Handling
Retry Strategy
Retry Logic
Poison Queue
Messages that fail repeatedly are moved to poison queue:Deployment
Environment Variables
Docker
Kubernetes
Deployment
Performance Considerations
Batch Processing
Process up to 32 messages per batch for efficiency
Parallel Processing
Multiple instances process queue concurrently
Async Operations
Non-blocking I/O for database and storage operations
Backoff Strategy
Exponential backoff prevents queue thrashing
Monitoring
Metrics to Track
- Queue Depth: Number of pending messages
- Processing Rate: Messages processed per minute
- Error Rate: Failed message percentage
- Latency: Time from enqueue to processing
- Poison Queue: Messages that failed repeatedly
Application Insights
Log custom metrics:Troubleshooting
Common Issues
Debug Logging
Self-Hosted Considerations
For self-hosted with queue processing:- Set up Azure Queue Storage or compatible service
- Configure connection strings
- Deploy Events Processor service
- Configure API service to enqueue events
Related Services
- Events Service - Event collection endpoint
- API Service - Enqueues events for processing
- Notifications Service - Real-time event notifications