Skip to main content
The Events Processor is a background service that processes events from Azure Queue Storage and manages event-driven integrations for audit logging and third-party services.

Overview

The Events Processor is primarily used in Bitwarden cloud deployments. Self-hosted instances typically handle events synchronously.
The Events Processor provides:
  • 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

From src/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

From src/EventsProcessor/Startup.cs:36:
Service Bus Listeners
Service Bus listeners enable:
  • 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
Azure Table Storage:
  • High-throughput writes
  • Cost-effective storage
  • Time-range queries
  • Scalable event log
Event Persistence

Middleware Pipeline

From src/EventsProcessor/Startup.cs:40:
Request Pipeline

Health Monitoring

The service exposes health check endpoints:

Alive Check

Response:

Version Check

Response:

Queue Configuration

Azure Queue Storage

Configure via environment variables:
Queue settings:
  • 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:
Topic features:
  • 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

Self-hosted deployments typically don’t need the Events Processor as events are processed synchronously.
For self-hosted with queue processing:
  1. Set up Azure Queue Storage or compatible service
  2. Configure connection strings
  3. Deploy Events Processor service
  4. Configure API service to enqueue events