EventsProcessor

Active contributors: Dirt (Data Insights & Reporting) team.

Purpose

src/EventsProcessor/ is the background drain for the event queue populated by Events and by direct IEventService calls in other services. It is a host with no HTTP surface area: just a Program.cs that boots the host and a Startup.cs that registers AzureQueueHostedService as the only hosted service.

Directory layout

src/EventsProcessor/
├── Program.cs
├── Startup.cs
├── AzureQueueHostedService.cs   # The single background worker
├── appsettings.*.json
└── Dockerfile / build.sh / entrypoint.sh

Key abstractions

Type	Path	Description
AzureQueueHostedService	src/EventsProcessor/AzureQueueHostedService.cs	Polls the events queue, batches messages, and calls IEventWriteService.CreateManyAsync with the parsed EventTableEntity instances.
IEventWriteService impls	src/Core/Services/Implementations/RepositoryEventWriteService.cs, TableStorageEventWriteService.cs, ...	The processor resolves to the persistent-write implementation (Repository / Cosmos / Azure Table).
IEventService (write path)	Used internally by other apps to publish events, not by EventsProcessor itself.

How it works

graph LR
    Q[("Azure Queue\n/Service Bus")] -->|batch| EPS[AzureQueueHostedService]
    EPS -->|deserialize| Events[EventTableEntity[]]
    Events -->|IEventWriteService| Sink[("Event table\n/ Cosmos / Azure Table")]

The hosted service runs at intervals controlled by globalSettings.Events.AzureServiceBusReceiveDelay and uses a backoff if the queue is empty. Failed messages are dead-lettered.

Integration points

• Events queue — connection from globalSettings.Events.ConnectionString. Same queue Events writes to.
• Database / Storage — IEventWriteService for the destination. In production cloud, audit events are stored in Cosmos DB and Azure Table Storage; in self-host the repository writer persists them straight to the SQL Event table.
• Mail / push — none. EventsProcessor is silent; downstream notifications are emitted from API code synchronously.

Self-host

Self-hosted instances ship EventsProcessor as one of the bundled containers. It is configured to drain the local Service Bus emulator (or the in-process queue) into the same SQL database the API reads from.

Entry points for modification

• Add a new sink → implement IEventWriteService in src/Core/Services/Implementations/ and register it in EventsProcessor.Startup based on configuration.
• Tune throughput → adjust the queue batch size and poll interval in globalSettings.Events.
• Change schema of the Event table → migrate it via util/Migrator/DbScripts/ and update EventTableEntity (src/Core/Entities/) plus the EF mapping.