Hangfire Background Job Processing POC
Author(s)
- Yeasa Mondal
Submission Date
[2026/02/11]
Version History
| Version | Date | Changes | Author |
|---|---|---|---|
| 1.0 | 2026-02-11 | Initial draft | Yeasa Mondal |
Objective
Implement Hangfire, an open-source background job processing framework for .NET, to manage and schedule recurring integration jobs with improved reliability, persistence, and monitoring capabilities.
Key Goals:
- Run tasks in the background outside the main request/response flow
- Provide reliability, persistence, and automatic retries
- Replace complex manual scheduling logic with CRON expressions
- Enable individual job control and monitoring through Hangfire Dashboard
Scope
Current State
We currently have:
- 9 different sync jobs: Salesforce, Authenticom, DealerTrend, Campaign, CTM, GoogleAds, CDK, MetaAds, AdsCreatives
- Single BackgroundService managing all syncs
- Two scheduling modes: Daily (fixed times) or Interval (same interval for everything)
- Manual scheduling logic that's becoming complex with multiple time calculations
Proposed Solution
Migrate to Hangfire for background job processing with:
- Individual recurring jobs for each integration
- CRON expression-based scheduling
- Dashboard for monitoring and manual control
- PostgreSQL-backed persistence
- Automatic retry logic with exponential backoff
Related Features
- Feature 1: Background job processing and scheduling system
- Feature 2: Integration service job management
- Feature 3: Monitoring and operational visibility for recurring jobs
- Feature 4: Distributed job execution with proper locking
Technical Approach
Why Hangfire?
Pros:
-
Built for this exact use case - Recurring jobs with different schedules
-
CRON expressions - Powerful, flexible scheduling (e.g.,
0 */2 * * *for every 2 hours)there are 5 fields:
┌──────── Minute (0 - 59)
│ ┌────── Hour (0 - 23)
│ │ ┌──── Day of month (1 - 31)
│ │ │ ┌── Month (1 - 12)
│ │ │ │ ┌─ Day of week (0 - 6) (Sunday = 0)
│ │ │ │ │
│ │ │ │ │
* * * * * -
Dashboard - Monitor job execution, see failures, retry manually
-
Persistence - Jobs survive application restarts (stores in PostgreSQL)
-
Retry logic - Automatic retry with exponential backoff
-
Distributed - Can scale across multiple instances with proper locking
-
No complex timer logic - Hangfire handles all scheduling complexity
-
Individual job control - Enable/disable/reschedule jobs independently
Cons:
- Additional dependency (but it's mature and well-maintained)
- Database overhead (but minimal for our scale)
- Learning curve (but straightforward)
Alternative Solutions (Less Optimal)
| Solution | Pros | Cons |
|---|---|---|
| Quartz.NET | Very powerful, cron support | More complex than Hangfire, steeper learning curve |
| Multiple BackgroundServices | Simple, no dependencies | Hard to manage configs, no dashboard, reinventing scheduling |
| Azure Functions/AWS Lambda | Serverless, scalable | Architectural shift, cost considerations, not on-premise friendly |
| NCrontab + BackgroundService | Lightweight | Still need to build retry logic, monitoring, persistence |
Implementation Plan
1. NuGet Packages to Add
Hangfire.Core(core functionality)Hangfire.AspNetCore(ASP.NET Core integration)Hangfire.PostgreSql(PostgreSQL storage)
2. Files to Create
IntegrationService/Jobs/SalesforceRecurringJob.csIntegrationService/Jobs/AuthenticomRecurringJob.csIntegrationService/Jobs/DealerTrendRecurringJob.csIntegrationService/Jobs/CampaignRecurringJob.csIntegrationService/Jobs/CtmRecurringJob.csIntegrationService/Jobs/GoogleAdsRecurringJob.csIntegrationService/Jobs/CdkRecurringJob.csIntegrationService/Jobs/MetaAdsRecurringJob.csIntegrationService/Jobs/AdsCreativesRecurringJob.csIntegrationService/Configuration/SyncJobConfig.cs(strongly-typed config)IntegrationService/Configuration/HangfireConfig.cs
3. Files to Modify
Program.cs- Add Hangfire setupappsettings.json- Add new config structureappsettings.Development.json- Dev-specific schedulesappsettings.Staging.json- Staging schedulesappsettings.Production.json- Production schedules
4. Files to Delete/Deprecate
ClientStatisticsSyncScheduler.cs(replace with Hangfire)- Old
ClientStatisticsSyncconfig section
5. Database Changes
Hangfire will auto-create its schema tables:
hangfire.jobhangfire.statehangfire.jobparameterhangfire.jobqueue- etc. (about 10 tables)
Separate schemas per service:
- IntegrationService →
hangfire_integration - Future services →
hangfire_[servicename]
Core Benefits of Hangfire Dashboard
- Observability - You can SEE what's happening
- Manual Control - Operational superpower
- Failure Debugging - Huge in production
- Long-running Job Detection - Detect jobs taking too long
- Proof for Business/QA - Concrete evidence of job execution
- Queue & Throughput Insight - Monitor system performance
Development Tasks & Estimates
| No | TaskName | Estimate (Hours) | Dependencies | Notes |
|---|---|---|---|---|
| 1 | Add Hangfire NuGet packages and setup | 2 hours | No dependency | Core, AspNetCore, PostgreSql packages |
| 2 | Create individual job classes (9 jobs) | 6 hours | Task 1 | One class per integration |
| 3 | Create configuration classes | 2 hours | Task 1 | SyncJobConfig, HangfireConfig |
| 4 | Modify Program.cs and configure Hangfire | 3 hours | Task 1, 3 | Add services, middleware, dashboard |
| 5 | Update appsettings files (all environments) | 2 hours | Task 3 | Dev, Staging, Production configs |
| 6 | Database schema setup and testing | 2 hours | Task 4 | Verify auto-creation of Hangfire tables |
| 7 | Migrate existing job logic to new jobs | 8 hours | Task 2 | Port sync logic to new job classes |
| 8 | Remove deprecated scheduler files | 1 hour | Task 7 | Clean up old BackgroundService |
| 9 | Testing and validation | 4 hours | All tasks | Test all jobs, dashboard, retries |
| 10 | Documentation and team training | 2 hours | All tasks | Document new system, training session |
| Total | 32 hours | ~4 developer days |
Testing & Validation
Test Scenarios
-
Job Scheduling Tests
- Verify each job runs at correct CRON schedule
- Test manual job triggering from dashboard
- Validate job execution across different environments
-
Persistence Tests
- Stop and restart application
- Verify jobs resume correctly
- Check database state persistence
-
Retry Logic Tests
- Simulate job failures
- Verify automatic retry with exponential backoff
- Test manual retry from dashboard
-
Dashboard Tests
- Access dashboard UI
- Monitor job execution in real-time
- Test job management features (pause, resume, delete)
-
Distributed Execution Tests
- Run multiple application instances
- Verify proper job locking
- Ensure no duplicate executions
-
Performance Tests
- Monitor database overhead
- Verify concurrent job execution
- Check system resource usage
Success Criteria
- All 9 integration jobs running on individual schedules
- Dashboard accessible and showing job history
- Jobs surviving application restarts
- Failed jobs automatically retrying
- No manual timer logic required
- Clean removal of old scheduler code
Risks & Mitigations
| Risk | Impact | Probability | Mitigation |
|---|---|---|---|
| Database overhead from Hangfire tables | Medium | Low | Hangfire is optimized for minimal overhead; monitor performance |
| Learning curve for team | Low | Medium | Provide training session and documentation |
| Migration issues from old scheduler | High | Medium | Thorough testing in dev/staging before production |
| Dashboard security concerns | High | Medium | Implement proper authentication and authorization |
| Job execution conflicts during migration | High | Low | Deploy during maintenance window with proper rollback plan |
| Dependency on external library | Medium | Low | Hangfire is mature, well-maintained, and widely used |
| Configuration complexity | Low | Medium | Create clear documentation and strongly-typed config classes |
Rollback Plan
- Keep old scheduler code temporarily
- Deploy Hangfire alongside existing system initially
- Gradual migration: one job at a time
- Monitor for 48 hours before full cutover
- Quick rollback available if issues detected
Conclusion
Hangfire is the optimal solution for managing our 9 recurring integration jobs. It provides:
- Simplified scheduling with CRON expressions instead of complex manual timer logic
- Built-in reliability with persistence and automatic retries
- Operational visibility through the comprehensive dashboard
- Scalability with distributed execution support
- Reduced maintenance by eliminating custom scheduling code
The estimated 32 hours of implementation time is justified by:
- Immediate operational improvements
- Reduced complexity in codebase
- Better monitoring and debugging capabilities
- Future-proof architecture for additional background jobs
Recommendation: Proceed with Hangfire implementation as outlined in this POC.
Next Steps
- Get approval for implementation
- Set up development environment with Hangfire
- Create first job as proof of concept
- Plan phased rollout strategy
- Schedule team training session