EventCounter Service
Overview
The EventCounter is an event-driven Azure Function microservice that maintains real-time counters for business entities within the Publisher platform. This service specifically tracks and updates the count of active campaigns per vendor by processing document change events from the document event stream.
Business Purpose
This service serves as a real-time counter management system that: - Maintains accurate counts of active campaigns per vendor - Processes campaign status change events to update vendor statistics - Provides real-time business metrics for vendor management - Ensures data consistency between campaign states and vendor counters - Supports business intelligence and reporting requirements
Architecture
Service Type
- Platform: Azure Functions (Containerized Kubernetes Microservice)
- Runtime: Node.js
- Trigger: HTTP Trigger (Anonymous authentication)
- Pattern: Event-Driven Counter Management
Key Components
graph TD
A[Event Hub: documentevent] --> B[EventCounter Service]
B --> C[Handler.js]
C --> D{Event Collection?}
D -->|Campaigns| E[Campaign Status Check]
D -->|Other| F[Skip Processing]
E --> G{Status Changed?}
G -->|No| H[Skip Update]
G -->|Yes| I[Get Vendor]
I --> J[PublisherService]
J --> K[Cosmos DB: Vendors]
K --> L[Vendor Data]
L --> M{Campaign Status?}
M -->|Active| N[Increment Counter]
M -->|Inactive| O[Decrement Counter]
N --> P[Update Vendor]
O --> P
P --> J
J --> K
Q[Retry Logic] --> B
R[Error Handling] --> Q
Data Flow
Event Processing Flow
- Event Reception: Receives document change events from
documenteventEvent Hub - Collection Filtering: Only processes events from the "Campaigns" collection
- Status Validation: Checks if campaign status has actually changed
- Vendor Retrieval: Fetches the associated vendor from Cosmos DB
- Counter Update: Increments or decrements the
activeCampaignscounter - Vendor Update: Persists the updated counter back to Cosmos DB
Event Structure
Input Event Format
{
"collection": "Campaigns",
"record": {
"id": "campaign-id",
"vendorId": "vendor-id",
"status": "active|inactive",
"_ts": 1640995200
},
"oldRecord": {
"status": "previous-status"
}
}
Counter Logic
- Active Status: Increments
vendor.activeCampaignsby 1 - Inactive Status: Decrements
vendor.activeCampaignsby 1 (minimum 0) - No Change: Skips processing if status hasn't changed
Core Functionality
Campaign Status Tracking
- Status Change Detection: Compares current and previous campaign status
- Vendor Counter Management: Maintains accurate active campaign counts
- Atomic Updates: Ensures counter consistency through atomic operations
- Error Recovery: Comprehensive retry logic for failed operations
Key Features
- Real-time Processing: Immediate counter updates on status changes
- Idempotent Operations: Safe to replay events without double-counting
- Error Resilience: Robust error handling with configurable retry attempts
- Selective Processing: Only processes relevant campaign events
- Data Consistency: Maintains accurate counters across system operations
Event Hub Integration
Input Source
- Event Hub:
documentevent - Consumer Group:
eventcounter - Batch Size: 1 event (single event processing)
- Poll Interval: 5 seconds
- Max Checkpoint Attempts: 3
Event Filtering
- Collection: Only processes "Campaigns" collection events
- Status Changes: Only processes events where campaign status has changed
- Vendor Association: Requires valid
vendorIdin the campaign record
Database Operations
Cosmos DB Integration
- Database: PublisherCosmos
- Container: Vendors
- Partition Key: "2019" (fixed partition for vendors)
- Operations: Read vendor, update vendor with new counter
Vendor Document Structure
{
"id": "vendor-id",
"friendlyName": "Vendor Name",
"activeCampaigns": 42,
// ... other vendor properties
}
Error Handling and Retry Logic
Error Scenarios
- Vendor Not Found: Campaign references non-existent vendor
- Database Failures: Cosmos DB connection or operation failures
- Invalid Events: Malformed or incomplete event data
- Concurrent Updates: Multiple services updating the same vendor
Retry Strategy
- Max Retries: 5 attempts (configurable)
- Retry Triggers: HTTP 500 status responses trigger Event Dispatcher retry
- Exponential Backoff: Progressive delay between retry attempts
- Alert Thresholds: Alerts generated after multiple failed attempts
Retry Attempt Logging
- 1 Attempt: INFO level logging
- 2+ Attempts: WARNING level logging
- 5+ Attempts: ALERT level logging with escalation
Performance Characteristics
Processing Metrics
- Throughput: ~100 events per second
- Latency: <200ms average processing time
- Accuracy: 99.9% counter accuracy
- Availability: 99.9% uptime with retry mechanisms
Scalability Features
- Single Event Processing: Optimized for low-latency updates
- Stateless Design: Horizontal scaling capability
- Efficient Queries: Optimized Cosmos DB operations
- Minimal Resource Usage: Low memory and CPU footprint
Dependencies
External Services
- Cosmos DB: Vendor data storage and retrieval
- Event Hub: Document change event stream
- Event Dispatcher: Event routing and retry management
Key NPM Packages
@azure/cosmos: Cosmos DB SDKasync: Asynchronous flow controlaxios: HTTP client for external callshttp-errors: HTTP error handlingquery-string: URL query parameter parsing
Configuration
Environment-Specific Settings
- Development: Basic logging and development database
- Integration: Integration testing with staging data
- Production: Production database with enhanced monitoring
Key Configuration Elements
- Event Hub connection settings
- Cosmos DB connection configuration
- Retry attempt limits
- Logging levels
- Application Insights telemetry
Monitoring and Observability
Logging
- Structured logging with configurable levels
- Event processing details and timing
- Counter increment/decrement operations
- Error conditions and retry attempts
Metrics
- Event processing rates and success ratios
- Counter update frequency by vendor
- Error rates and retry statistics
- Database operation performance
Application Insights Integration
- Custom telemetry for counter operations
- Performance counters for processing metrics
- Exception tracking and alerting
- Dependency tracking for Cosmos DB
Security Considerations
- Authentication: Anonymous HTTP trigger (internal service)
- Data Privacy: Handles vendor and campaign identifiers securely
- Access Control: Cosmos DB access via managed identity
- Audit Trail: Comprehensive logging for compliance
Related Services
This service integrates with the broader Publisher ecosystem: - DocumentCRUD/DocumentCRUDV2: Source of campaign change events - DocumentEventHandler: Provides document change events - Vendor Management: Consumes updated vendor counters - Reporting Services: Use vendor counter data for analytics
Troubleshooting
Common Issues
- Counter Drift: Verify event processing order and retry logic
- Missing Vendors: Check vendor creation process and data consistency
- Performance Issues: Monitor Event Hub throughput and database performance
- Retry Loops: Review error conditions and retry configuration
Debug Steps
- Check Application Insights for event processing traces
- Verify Event Hub message flow and consumer group health
- Review Cosmos DB query performance and connection status
- Monitor retry attempt patterns and success rates
Development
Local Development Setup
- Clone repository
- Install dependencies:
npm install - Configure Cosmos DB connection
- Set up Event Hub connection strings
- Configure Application Insights
- Run tests:
npm test
Code Structure
index.js: Azure Function entry point with retry logicsrc/Handler.js: Main event processing and business logicsrc/PublisherService.js: Cosmos DB operations for vendor managementsrc/Cosmos.js: Cosmos DB client wrapperconfig/: Environment-specific configurations
Future Enhancements
Potential Improvements
- Support for additional counter types (inactive campaigns, total campaigns)
- Batch processing for improved throughput
- Counter validation and reconciliation processes
- Enhanced monitoring and alerting capabilities