A user clicks a button.
Your server starts doing ten things.
The browser waits.
Five seconds later, the user is still staring at a loading spinner.
This is often a sign that too much work is happening inside the request itself.
Not Everything Needs to Happen Immediately
Consider sending an email.
The user doesn't necessarily need your application to wait for the email provider before returning a response.
The same idea applies to:
Generating reports Processing images Sending notifications Importing large datasets Generating files Running scheduled calculations
These are good candidates for background jobs.
The Better Flow
Instead of:
User ↓ Request ↓ Do everything ↓ Response
you can use:
User ↓ Request ↓ Create job ↓ Response ↓ Worker processes job
The user gets a response faster.
The heavy work happens separately.
Background Jobs Need Reliability
Moving work into a queue doesn't automatically solve everything.
You also need to think about:
Retries Failed jobs Duplicate jobs Timeouts Monitoring Queue size
For important tasks, you want to know when something fails.
Don't Make the User Wait for Work They Don't Need to Watch
If a task takes 20 seconds but doesn't need to happen before the page can load, consider moving it into the background.
Your application becomes more responsive.
Your infrastructure becomes easier to scale.
And the user doesn't have to stare at a spinner while your server does work that could happen separately.
Fast applications aren't always doing less work. Sometimes they're simply doing the work at the right time.