What are Django signals?

Question

Accepted Answer

**Signals** are Django's implementation of the observer pattern — they let certain senders notify a set of receivers when specific **events** occur (like a model being saved or deleted). They enable **decoupled** code: one part of the app reacts to events in another without direct coupling.

## Common built-in signals

```text
pre_save / post_save      → before / after a model instance is saved
pre_delete / post_delete  → before / after a model instance is deleted
m2m_changed               → a ManyToMany relationship changed
request_started / finished→ request lifecycle
user_logged_in / out      → authentication events
```

## Connecting a receiver to a signal

```python
from django.db.models.signals import post_save
from django.dispatch import receiver

# automatically create a Profile whenever a User is created
@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
    if created:                          # only on creation, not every save
        Profile.objects.create(user=instance)
```

The `@receiver` decorator connects a function to a signal for a specific sender. When a `User` is saved, Django calls this function — here, auto-creating a related `Profile`. The `created` flag distinguishes creation from updates.

## A typical use case

```python
@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
    if created:
        send_email(instance.customer.email, "Order confirmed")
# the Order-creation code doesn't need to know about emails → decoupled
```

The order-creating code stays focused on orders; the email logic lives separately and reacts to the event — keeping concerns decoupled.

## When signals are useful

```text
✓ Reacting to model events from a DIFFERENT app/module (decoupling)
✓ Auto-creating related objects (Profile on User creation)
✓ Cache invalidation, search-index updates, audit logging on save/delete
✓ Cross-cutting reactions you don't want to embed in the core logic
```

## The important caveat: signals can hurt clarity

```python
# ⚠️ signals create IMPLICIT, "action at a distance" behavior:
# saving an Order triggers an email somewhere else — not obvious from the save call.
# This can make code HARDER to follow and debug.
```

```text
When to PREFER explicit code over signals:
  ✗ If the logic clearly belongs in the same flow → call it directly (more readable)
  ✗ Overusing signals → hidden, hard-to-trace behavior, debugging difficulty
  ✓ A common alternative: override the model's save() method, or use a service function,
    for logic tightly coupled to the operation
Use signals mainly for genuine DECOUPLING (reacting across app boundaries), not as
a default for all post-save logic.
```

## Why it matters

Signals are a useful Django feature for **decoupling** code — letting different parts of an application react to events (model saves/deletes, auth events) without direct dependencies, which is valuable for cross-cutting concerns like auto-creating related objects, cache invalidation, audit logging, and reacting to events across app boundaries.

Understanding them is important both for *using* them appropriately and for recognizing them in existing codebases (they're a common source of "why did this happen?" confusion).

However, what makes signals a particularly important topic is the **nuanced judgment about when to use them**: while they enable elegant decoupling, they also create **implicit, "action-at-a-distance" behavior** that can make code harder to follow and debug (saving an object mysteriously triggers effects defined elsewhere).

Mature Django developers understand this trade-off — using signals for *genuine* decoupling (reacting across module/app boundaries to events you shouldn't couple to the source) while preferring **explicit code** (calling logic directly, overriding `save()`, or using service functions) when the logic clearly belongs in the same flow, because explicit code is more readable and traceable.

Knowing how signals work (connecting receivers, the `created` flag, common signals), their legitimate use cases, and crucially **when NOT to use them** (avoiding hidden, hard-to-debug behavior) reflects practical, experienced understanding that distinguishes developers who write maintainable Django code from those who overuse signals and create tangled, opaque applications.