Mengapa Pekerjaan Dipindahkan dari Request

Some work is slow: sending email, resizing images, calling APIs. If you do it inside a view, the user waits for all of it. ⏳

A request that runs slow work blocks the worker handling it. While it waits, that worker cannot serve anyone else.

Every second a view spends on background-ish work is a second the browser shows a spinner. Slow responses feel like a broken app.

A task queue lets a view hand slow work to a separate process, then return a response right away while work runs later.

Celery is the most common task queue for Flask. Your app pushes jobs onto it, and worker processes pick them up and run them.

Your Flask app is the producer: it enqueues jobs. Separate Celery workers consume those jobs and do the heavy lifting.

A broker like Redis or RabbitMQ holds the queue of pending jobs. The app writes to it and workers read from it.

For email or logging you often do not need the result. The view enqueues the job, returns fast, and never blocks on it. ✉️

Sometimes you do want the result, like a finished report. Celery can store that result so you can poll for it once the job is done.

Move work that is slow, external, or bursty: emails, image processing, third-party API calls, report generation, and scheduled jobs.

A healthy view validates input, enqueues the slow part, and returns immediately. Heavy logic lives in the task, not the request.

Think about why we use a queue.

Slow work blocks views. A queue lets you enqueue it and respond fast. Celery is the producer-broker-worker pattern for Flask. ✅