ChokaQ.NET 10 Background Job Engine

A SQL-backed background job engine with typed jobs, retries, queue isolation, health checks, and The Deck dashboard.

Start Here

Try ChokaQ

storage

Durable SQL Storage

Accepted work is stored in JobsHot. Finished work moves to Archive, and failed work moves to DLQ for operator review.

code

Typed Jobs

Define a DTO, write a handler, register a type key, and enqueue work through IChokaQQueue.

shield

At-Least-Once Execution

ChokaQ can preserve and retry work, but handlers that touch external systems still need idempotency.

dashboard

The Deck

A real-time dashboard for active jobs, queues, DLQ, health, worker controls, and recovery workflows.

settings

Runtime Policy

Timeouts, retries, queue limits, health thresholds, SQL settings, and metrics caps live in configuration.

book

Detailed Documentation

The docs explain setup, runtime behavior, delivery guarantees, operator workflows, and the architecture behind durable processing.

What ChokaQ Is

ChokaQ is a background job engine for .NET applications.

In normal request/response code, the user waits while your app does everything. That is fine for quick work. It is not fine for slow or unreliable work like sending email, rendering reports, calling partner APIs, charging payments, or processing webhooks.

ChokaQ lets the request say: "store this work, run it in the background, and make its state visible."

The core idea is simple:

Your application enqueues a job.
ChokaQ stores the job.
A worker claims the job.
Your handler runs.
ChokaQ records the final state.
Operators can inspect what happened in The Deck.

The Mental Model

Think about ChokaQ as three cooperating parts:

Part	Plain explanation	Why it matters
Job storage	The durable notebook of accepted work.	Jobs can survive process restarts in SQL Server mode.
Workers	The background runners that claim and execute jobs.	Work happens outside the request path.
The Deck	The operator window into the system.	People can see lag, failures, queues, retries, and DLQ rows.

The most important table is JobsHot. It contains active work: jobs waiting to run, jobs fetched by a worker, and jobs currently processing. Finished jobs move out of Hot so the active-work table stays small.

What To Read First

If you are new to ChokaQ, start with Runtime Model. It explains where ChokaQ runs, how it stores work, and how your handlers are called. Then continue with Overview for the broader tour.

If you want to run code immediately, start with Try ChokaQ. It gives you a SQL-backed sample, The Deck, health checks, and scenario buttons in one short path.

If you are evaluating reliability, read Delivery Guarantees before writing a handler that sends email, charges money, or calls another system.

If you want to understand the architecture, read Three Pillars, State Machine, and SQL Concurrency.

Data Flow

Step	What happens	Human meaning
Enqueue	A job is inserted into `JobsHot`.	The system accepted the work.
Fetch	A worker claims eligible work with SQL locking.	One worker owns the job now.
Processing	The handler runs user code.	Your business operation is happening.
Success	The row moves to Archive.	The job finished normally.
Retry	The row stays in Hot with a future schedule.	Try again later without sleeping a thread.
DLQ	The row moves to Dead Letter Queue.	A human or repair workflow should inspect it.

Start Small

Run the sample first, then read the docs while looking at The Deck. The UI makes the architecture easier to understand because you can see jobs move between states instead of only reading about them.