Implementing Password Reset Emails with Celery Tasks in Django

Today, I completed the implementation of password reset emails using Celery tasks in my Placement Portal.

The password reset functionality itself was already working.

The problem was the way the email was being delivered.

Previously, the Django API endpoint was responsible for sending the password reset email directly from the view.

That meant the user had to wait for the email-related operations to complete before receiving the API response.

It worked.

But it wasn't the user experience I wanted.

So I moved the email delivery into a Celery background task.

The Previous Password Reset Flow

Before introducing Celery, the password reset request followed this sequence:

1. Generate the password reset token.
2. Create the frontend password reset URL.
3. Prepare the email subject and content.
4. Render the email template.
5. Send the email through SMTP.
6. Wait for the SMTP server to respond.
7. Return the API response.

The problem wasn't the password reset logic.

The problem was that email delivery was part of the request-response cycle.

The API couldn't finish until the email operation had finished.

That created an unnecessary delay for the user.

Why Email Can Slow Down an API

Email delivery is an I/O-bound operation.

My Django application depends on an external SMTP service to actually deliver the message.

That introduces factors outside the application's direct control.

For example:

• Network latency.
• SMTP authentication.
• Email provider response time.
• Temporary service slowdowns.

Even if the delay is only a few seconds, those seconds are noticeable when a user is simply requesting a password reset link.

From the user's perspective, the expected interaction is simple:

Enter email → Request reset → Receive confirmation

They shouldn't have to wait for the entire email delivery process before the API responds.

The Celery Implementation

I moved the email delivery logic into a Celery background task.

The new flow looks like this:

User
  ↓
Password Reset Request
  ↓
Django API
  ↓
Generate Token
  ↓
Create Email Task
  ↓
Return API Response
  │
  └──────────────→ Celery Worker
                       ↓
                   Send Email
                       ↓
                  SMTP Server

The important change is where the email operation happens.

The Django view is no longer responsible for waiting for the email to be delivered.

Instead, it creates a background task and delegates the email operation to Celery.

The Celery Worker then processes that task independently.

What Changed for the User?

From the user's perspective, the password reset flow remains almost exactly the same.

They still:

1. Enter their registered email address.
2. Submit the password reset request.
3. Receive a success response.
4. Receive the password reset email.
5. Click the reset link.
6. Set their new password.

The difference is what happens behind the scenes.

Previously:

API Request
    ↓
Send Email
    ↓
Wait
    ↓
API Response

Now:

API Request
    ↓
Create Background Task
    ↓
API Response

And independently:

Celery Worker
    ↓
Process Task
    ↓
Send Email

The user no longer needs to wait for the SMTP operation to complete before receiving the API response.

Benefits of the Implementation

Moving password reset email delivery into Celery gives me several immediate architectural benefits.

Faster API Responses

The biggest improvement is that the API doesn't have to wait for email delivery.

The request can complete much sooner because the slower operation has been delegated to a background worker.

Better User Experience

Password reset is usually a time-sensitive interaction.

Users don't care which SMTP server is being used or how the email is generated.

They simply want to know that their request was accepted.

Moving email delivery into the background makes that interaction feel faster and more responsive.

Separation of Responsibilities

The Django application handles the password reset request.

Celery handles the background email task.

The SMTP server handles email delivery.

Each component has a more focused responsibility.

This makes the overall architecture easier to reason about.

Foundation for Future Background Tasks

The implementation also gives me a foundation for other workloads that shouldn't block API requests.

For example:

• Notification emails.
• Invitation emails.
• Bulk email delivery.
• Resume parsing.
• File processing.
• Application status notifications.
• Scheduled background operations.

Not all of these are implemented yet.

But the infrastructure is now capable of supporting this style of background processing.

A Small Implementation With a Bigger Lesson

At first glance, moving one email operation to Celery might not seem like a major architectural change.

But it taught me something important.

The question isn't always:

"How can I make this operation faster?"

Sometimes the better question is:

"Does this operation need to happen before I respond to the user?"

In my case, the answer was no.

The password reset request could be accepted immediately while the email was processed separately.

That changed the solution completely.

Final Thoughts

One of the things I'm enjoying most while building this Placement Portal is how small features often expose larger architectural decisions.

Password reset initially looked like a straightforward authentication feature.

Then email delivery became a performance problem.

That led me to background processing.

And that eventually led to Celery, RabbitMQ, workers, monitoring, and a broader communication architecture.

The actual implementation may be small.

But the lesson is bigger:

Users shouldn't have to wait for work that doesn't need to happen before their request can be completed.

Sometimes improving software isn't about adding another feature.

It's simply about moving the work to the right place.

— Abhishek Roka