How karthik-valmiki/asyncz works
AsyncZ accepts jobs over HTTP, persists them before enqueueing, and returns an ID for polling. Workers execute jobs asynchronously, record attempts, retry failures, and send exhausted or zombie jobs to a dead-letter queue. The README documents these recovery capabilities; worker excerpts are partial, so internal steps not shown there are represented only where documented.
Main entry points: main.py FastAPI · worker.py Worker · db.py DB Sessions · redis_client.py ARQ Client
Components 16
HTTP API
- FastAPI
app/main.py - API Schemas
app/schemas.py - Job Status
app/main.py
Durable State
- DB Sessions
app/db.py - Job Models
app/models.py - PostgreSQL
- Attempt Audit
app/models.py
Job Processing
- ARQ Client
app/redis_client.py - ARQ Queue
app/redis_client.py - Redis
- Worker
app/worker.py - Payload Execution
app/worker.py - Zombie Recovery
app/worker.py
Monitoring
- Dead Letter Queue
app/main.py - Health Checks
app/main.py
Other components
- Client
Connections 22
- Client → FastAPI: submits or polls
- FastAPI → API Schemas: validates and formats
- FastAPI → DB Sessions: reads and writes
- FastAPI → Job Models: queries jobs
- DB Sessions → PostgreSQL: persists state
- FastAPI → ARQ Client: enqueues job
- ARQ Client → ARQ Queue: pushes job
- ARQ Queue → Redis: stores queued work
- Redis → Worker: dispatches jobs
- Worker → DB Sessions: loads and updates
- Worker → Job Models: uses job records
- Worker → Attempt Audit: records attempts
- Worker → Payload Execution: runs payload
- Payload Execution → Worker: returns outcome
- Worker → Redis: retries or dead-letters
- Worker → Zombie Recovery: runs scheduled scan
- Zombie Recovery → DB Sessions: finds stale jobs
- Zombie Recovery → Redis: re-enqueues or dead-letters
- FastAPI → Redis: reads DLQ and health
- FastAPI → Job Status: returns job state
- FastAPI → Health Checks: checks dependencies
- FastAPI → Client: returns response