Background work changes the reliability model
Sending email, generating reports, syncing CRMs, and calling external APIs are often better outside the request path. But once the work moves to a queue or worker, you need a plan for retries, duplicates, and partial failure.
A job that can run twice must either be safe to repeat or able to detect that it already completed.
Use outbox thinking for side effects
The outbox pattern records intended side effects in the same transaction as the business state change. A worker later delivers those side effects and marks them complete.
This prevents the classic problem where the database write succeeds but the message enqueue fails, or the external side effect succeeds but your app never records it.
Order saved -> Outbox row created -> Worker sends email
-> Mark outbox row deliveredTry the idea
API boundary map
Click a layer to see what it should own.
Accept HTTP input, bind route/body data, return a typed response.
app.MapPost("/invoices", CreateInvoice)Workers need operational UI too
A production job system should expose failed jobs, retry counts, last error, and safe manual retry paths.
Production notes for .NET APIs
Backend code becomes maintainable when HTTP boundaries, service boundaries, and persistence boundaries are named. A route that works once is not the same as an API that another developer can safely extend.
Before shipping, review lifetimes, validation behavior, request contracts, logging, and the exact error shape that frontend code will receive.
Conclusion
Background jobs are production features. Treat them as workflows with state, recovery, and ownership.