What this prompt does
This prompt builds reliable background services for a [dotnet_version] app handling [service_purposes]. It is structured around the patterns that make background work trustworthy: a BackgroundService doing [worker_task] with backoff, a [schedule_pattern] scheduler using [timer_approach] for [scheduled_task], a queue consumer reading [queue_source] and processing [message_type] at concurrency [concurrency] with ordering for [ordering_requirement], graceful shutdown draining work within [shutdown_timeout] into [recovery_store], error strategies for [transient_errors] and [permanent_errors], health checks, and telemetry via [telemetry_tool].
The variables decide the shape of each worker. [queue_source] and [message_type] define the consumer, [concurrency] and [ordering_requirement] balance throughput against correctness, and [shutdown_timeout] plus [recovery_store] ensure in-flight work survives a deploy. The error-strategy variables split failures into retry, dead-letter, and circuit-breaker paths so transient blips are handled differently from permanent ones. That distinction is what keeps a background service from either dropping real work or looping forever on a poison message, and the circuit breaker around [external_dependency] stops one flaky upstream from taking the whole worker down with it.
When to use it
- An app needs reliable background work: queue processing, scheduled jobs, or data sync
- You want graceful shutdown so in-flight work is never silently lost on deploy
- Building a queue consumer with a concurrency cap and ordered processing where required
- Adding a
[schedule_pattern]scheduler that avoids overlapping executions - You need health checks reporting queue depth and last successful processing time
- Wiring structured logs and metrics through
[telemetry_tool]
Example output
Expect several worker implementations: a BackgroundService class with cancellation and backoff, a scheduler using [timer_approach], a queue processor with a SemaphoreSlim-style concurrency limit, IHostApplicationLifetime shutdown hooks persisting to [recovery_store], error-handling branches, IHealthCheck implementations, and telemetry instrumentation. Each comes as focused code plus explanation rather than one combined service.
Pro tips
- Set
[shutdown_timeout]to a value your platform actually allows; Kubernetes SIGTERM-to-SIGKILL windows are finite, so a long drain timeout may be cut off - Choose
[recovery_store]carefully — persisting in-flight state is what lets a restarted worker resume instead of dropping messages - Match
[concurrency]to downstream limits; high parallelism against a rate-limited API just shifts the failure to transient errors - Keep
[ordering_requirement]narrow (for example per order ID) so you don't serialize the whole queue unnecessarily - Distinguish
[transient_errors]from[permanent_errors]explicitly so retries don't loop forever on a malformed payload - Have the health check expose queue depth and last-success time; a worker that is alive but stuck is invisible without it
- Use exponential backoff on the
[worker_task]failure path so a transient outage does not turn into a tight retry loop hammering the upstream API - Emit metrics for processing rate and queue lag through
[telemetry_tool]; lag trending up is the earliest sign the worker cannot keep pace with incoming volume
