# Job Processing Flow This diagram shows the detailed flow of how compute workers process backtest jobs from the queue. ```mermaid flowchart TD Start([User Creates
BundleBacktestRequest]) --> CreateJobs[API: Generate
BacktestJobs] CreateJobs --> InsertDB[(Insert Jobs
Status: Pending)] InsertDB --> WorkerPoll{Worker Polls
Database} WorkerPoll -->|Every 5s| CheckJobs{Jobs
Available?} CheckJobs -->|No| Wait[Wait 5s] Wait --> WorkerPoll CheckJobs -->|Yes| ClaimJobs[Claim Jobs
Advisory Lock] ClaimJobs --> UpdateStatus[Update Status:
Running] UpdateStatus --> CheckSemaphore{Semaphore
Available?} CheckSemaphore -->|No| WaitSemaphore[Wait for
slot] WaitSemaphore --> CheckSemaphore CheckSemaphore -->|Yes| AcquireSemaphore[Acquire
Semaphore] AcquireSemaphore --> LoadCandles[Load Candles
from InfluxDB] LoadCandles --> ProcessBacktest[Process Backtest
CPU-intensive] ProcessBacktest --> UpdateProgress{Every
10%?} UpdateProgress -->|Yes| SaveProgress[Update Progress
in DB] SaveProgress --> ProcessBacktest UpdateProgress -->|No| ProcessBacktest ProcessBacktest --> BacktestComplete{Backtest
Complete?} BacktestComplete -->|No| ProcessBacktest BacktestComplete -->|Yes| SaveResult[Save Result
Status: Completed] SaveResult --> UpdateBundle[Update Bundle
Progress] UpdateBundle --> ReleaseSemaphore[Release
Semaphore] ReleaseSemaphore --> WorkerPoll style Start fill:#4A90E2 style ProcessBacktest fill:#50C878 style SaveResult fill:#FF6B6B style WorkerPoll fill:#FFD93D ``` ## Key Components - **Worker Polling**: Workers continuously poll database for pending jobs - **Advisory Locks**: PostgreSQL advisory locks prevent multiple workers from claiming the same job - **Semaphore Control**: Limits concurrent backtests per worker (default: CPU cores - 2) - **Progress Updates**: Progress is saved to database every 10% completion - **Bundle Updates**: Individual job completion updates the parent bundle request