Django Signals — ELI5

Think about a school bell. When the bell rings, students know it’s lunchtime. The bell doesn’t walk up to each student individually — it just rings, and everyone who cares about lunch reacts.

Django signals work the same way. When something important happens in your app — like a new user signing up or a blog post being saved — Django “rings a bell.” Any code that’s listening for that bell can react automatically.

The nice part is that the code doing the saving doesn’t need to know who’s listening. The signup form doesn’t know that somewhere else in the app, there’s code that sends a welcome email when a user is created. The form just saves the user, the signal fires, and the email code picks it up.

This keeps your code from getting tangled. Without signals, you’d have to stuff all the side effects — send email, log the event, update stats — into the same function. With signals, each reaction lives in its own place.

There’s a downside, though. Because these connections are invisible in the code, they can be hard to track down. When something unexpected happens after saving a record, you might spend a while hunting for the signal handler that’s responsible. It’s like hearing a noise in the house and not knowing which room it came from.

Signals are best for loose connections between different parts of your app. If two things are closely related, just call one from the other directly.

The one thing to remember: Django signals let separate pieces of code react to events without being directly connected — like a school bell that everyone can hear.