Django Signals are a dispatch mechanism that allows decoupled applications get notified when actions occur elsewhere in the framework. They implement the observer pattern, allowing senders to notify a set of receivers.
Sometimes when an event happens (like a user registering), multiple different parts of your system need to react (send a welcome email, create a user profile, log the event). Instead of putting all that code directly in the registration view, signals allow the view to just shout “A user registered!” and let other decoupled functions listen and react independently.
- A Signal instance is defined (e.g.,
post_save). - A receiver function is created and registered to listen to that signal using the
@receiverdecorator. - Somewhere in the code, an action occurs and the signal’s
.send()method is triggered. - Django synchronously loops through all registered receivers and executes them.
graph TD A[User Model Saved] -->|Triggers| B(post_save Signal) B --> C(Receiver: Create Profile) B --> D(Receiver: Send Email) B --> E(Receiver: Log to Audit)
Signals are like a fire alarm in a building. The person who pulls the alarm (sender) doesn’t have to go to every room to tell people to leave. The alarm broadcasts the event globally, and everyone (receivers) knows how to react independently.
from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import User, Profile
@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
if created:
Profile.objects.create(user=instance)- Synchronous: Receivers run in the same thread and block the request until they finish.
- Decoupled: Senders and receivers don’t need to know about each other.
- Built-in signals:
pre_save,post_save,pre_delete,post_delete.
- Built from: Django Web Framework — decoupled event system.
- Related: Django Model — mostly used to listen to model lifecycle events.
- Contrasts with: Django Celery Integration — celery is async, signals are sync.
- Misconception: People think signals are asynchronous background tasks. They are not. They run sequentially and can drastically slow down an API response.
- Can lead to “spaghetti code” where it’s hard to trace why a profile was mysteriously created when a user was saved.