What this prompt does
This prompt asks the AI to design a Celery- or Bull-style distributed task queue handling [tasks_per_second] tasks per second. It covers ten areas: a submission API with [priority_levels] priorities, at-least-once delivery, a configurable [retry_strategy], a dead letter queue, scheduled jobs, worker auto-scaling, progress tracking, persistence on [storage_backend], a monitoring dashboard, and multi-tenant rate limiting.
The structure works because queues are deceptively simple until you own retries, failures, and worker scaling in production. Passing [tasks_per_second] sizes the throughput the broker and worker pool must sustain. [priority_levels] shapes how the API and dispatcher route urgent versus bulk work, [retry_strategy] (like exponential backoff with jitter) decides how failures are re-attempted before hitting the dead letter queue, and [storage_backend] determines durability — a Redis-plus-PostgreSQL split gives speed for the queue and durability for job records. Asking for data model and lifecycle diagrams keeps the failure handling concrete.
When to use it
- You're standing up background job processing and need a real retry and DLQ design
- You run workers in production and want to formalize worker lifecycle and auto-scaling
- You need priority routing so
[priority_levels]like critical and bulk don't starve each other - You're choosing a
[storage_backend]and want the durability tradeoffs spelled out - You need scheduled/delayed jobs with cron-like semantics
- You're building multi-tenant infrastructure and need per-tenant rate limiting
Example output
Expect a design document: a job data model, a submission API contract, a dispatcher that honors [priority_levels], the [retry_strategy] with backoff math, a dead letter queue flow, a worker lifecycle description with auto-scaling triggers, and a monitoring section covering queue depth, throughput, and failure rate. It often includes a failure-handling flow diagram and a persistence schema for [storage_backend].
Pro tips
- Set
[tasks_per_second]to your real peak; it drives worker pool sizing and broker throughput decisions - Keep
[priority_levels]small and meaningful — too many tiers make the dispatcher complex without real benefit - Be explicit about
[retry_strategy]; exponential backoff with jitter prevents thundering-herd retries after an outage - Ask the model to detail when a job moves to the dead letter queue, not just that one exists
- Use a split
[storage_backend](fast broker plus durable store) if you need both low latency and an audit trail of job history - Push on the auto-scaling triggers — "scale workers" is useless without the metric and threshold that drives it
