Calling tasks asynchronously in Django - Step-by-Step Execution

Concept Flow - Calling tasks asynchronously

Define task function

↓

Trigger async call

↓

Task queued in broker

↓

Worker picks task

↓

Task runs in background

↓

Result stored or ignored

↓

Main app continues immediately

This flow shows how a task is defined, called asynchronously, queued, executed by a worker, and how the main app continues without waiting.

Execution Sample

Django

from celery import shared_task

@shared_task
def add(x, y):
    return x + y

add.delay(4, 6)

Defines a task to add two numbers and calls it asynchronously using delay().

Execution Table

Step	Action	Evaluation	Result
1	Define task function 'add'	Function 'add' ready for async	Task registered with Celery
2	Call add.delay(4, 6)	Creates async task message	Task message sent to broker queue
3	Worker receives task	Worker picks 'add' task with args (4,6)	Task starts running in background
4	Task executes add(4,6)	Calculates 4 + 6	Returns 10
5	Result stored or ignored	Result saved if backend configured	Main app not blocked, continues immediately

💡 Task completes asynchronously; main app never waits for result.

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
x	undefined	4	4	4
y	undefined	6	6	6
result	undefined	undefined	10	10

Key Moments - 3 Insights

Why doesn't the main app wait for the task result after calling add.delay(4, 6)?

Because add.delay() sends the task to a queue and returns immediately without blocking, as shown in execution_table step 2 and 5.

How does the worker know when to run the task?

The worker listens to the broker queue and picks tasks as they arrive, shown in execution_table step 3.

What happens if the result backend is not configured?

The task runs and completes, but the result is not stored or retrievable, so the main app cannot get the output.

Visual Quiz - 3 Questions

Look at the execution table, what is the result of add(4, 6) at step 4?

A Undefined

B 4

C 10

D 6

💡 Hint

Check the 'Result' column at step 4 in the execution_table.

At which step does the main app continue without waiting?

A Step 1

B Step 5

C Step 2

D Step 4

💡 Hint

Look at the 'Action' and 'Result' columns describing main app behavior.

If we call add(4, 6) directly instead of add.delay(4, 6), what changes in the execution?

A Main app waits for the result before continuing

B Task runs asynchronously as before

C Task is queued but not executed

D Worker ignores the task

💡 Hint

Compare the difference between synchronous call and delay() in the concept_flow.

Concept Snapshot

Define a task with @shared_task decorator.
Call task asynchronously with task.delay(args).
Task is queued and run by worker in background.
Main app continues immediately without waiting.
Result stored only if backend configured.
Use for long or slow operations to avoid blocking.

Full Transcript

In Django with Celery, you define a task function using @shared_task. When you call this task with .delay(), it sends a message to a broker queue and returns immediately. A worker process listens to this queue and runs the task in the background. The main application does not wait for the task to finish and continues its work. The task result can be stored if a result backend is set up, but the main app does not block waiting for it. This allows long-running tasks to run asynchronously without slowing down the user experience.