Immediate response or background job: when should a SaaS workflow become asynchronous?

A request should stay synchronous when a person can reasonably wait for a bounded result and the system can complete it reliably. Long, bursty, expensive, or failure-prone work often needs a background job, but a queue creates a new product workflow with status, retry, cancellation, and support states.

Identify the pressure that requires separation

Consider processing time, payload size, external API latency, traffic bursts, cost, timeout limits, and whether work must survive a browser closing. Imports, exports, media processing, large reports, notifications, and bulk integrations commonly exceed a safe request-response boundary.

Design the user contract

HTTP `202 Accepted` indicates that processing has been accepted but not completed; it does not promise eventual success. Give the user a durable job identifier, honest status, progress only where it is meaningful, a result or failure explanation, and a way to retry or contact support. Decide whether cancellation is possible and what happens to partial work.

Make processing safe to repeat

• Use idempotency or deduplication so a retry cannot create duplicate charges, messages, or records.
• Bound retries with backoff and distinguish transient failures from invalid work.
• Set time, memory, payload, concurrency, and third-party spending limits.
• Use a dead-letter or review path for jobs that exhaust automated recovery.
• Propagate tenant and authorization context without trusting stale client input.

Operate the queue as part of the product

Monitor queue age, completion time, failure and retry rates, worker saturation, and cost. Define who responds when work backs up and how users are informed. Queue-based load leveling can protect a service from bursts, but an unbounded queue merely delays overload and hides demand.

Kiwi can help design an asynchronous workflow and its user-facing states. High-volume distributed systems, regulated processing, and formal reliability commitments require architecture and operations appropriate to the risk.