2nd/10_Wiki/Topics/Backend/Django_Signals.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-django-signals	Django Signals	10_Wiki/Topics	verified	self	Django Signal Framework dispatch signals	none	A	0.9	applied	django python observer-pattern backend decoupling		2026-05-10	pending	language framework python django-5

Django Signals

매 한 줄

"매 in-process pub/sub for Django — observer pattern over the ORM lifecycle". Django signals 는 sender/receiver 의 decouple 하는 dispatch 메커니즘 — 2005 Django core 에 도입, 2026 현재 Django 5.1 LTS 까지 안정. 매 ORM hook (post_save, pre_delete) + custom signal 의 emit 의 standard way.

매 핵심

매 작동 원리

• django.dispatch.Signal: receiver list 의 weakref 보관 — 매 GC safe.
• send() vs send_robust(): send 의 raise on receiver error, send_robust 의 collect exceptions in result list — 매 production 의 send_robust 권장.
• Synchronous: 매 in-process, in-thread — 매 transaction.on_commit() 통해 post-commit 의 schedule.
• Async receivers (5.0+): 매 async def receiver 의 native support.

매 built-in signals

• Model: pre_save, post_save, pre_delete, post_delete, m2m_changed, pre_init, post_init.
• Request: request_started, request_finished, got_request_exception.
• Auth: user_logged_in, user_logged_out, user_login_failed.
• Migration: pre_migrate, post_migrate.

매 응용

1. Audit log — 매 model save 의 log 기록.
2. Cache invalidation — 매 ORM update 시 cache key purge.
3. Side-effect dispatch — 매 user signup → email send.

💻 패턴

Receiver registration with @receiver

# myapp/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.conf import settings

from .models import Profile

@receiver(post_save, sender=settings.AUTH_USER_MODEL)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

AppConfig.ready() 의 signal import

# myapp/apps.py
from django.apps import AppConfig

class MyAppConfig(AppConfig):
    name = "myapp"

    def ready(self):
        from . import signals  # noqa: F401 — register receivers

Custom signal

# myapp/signals.py
from django.dispatch import Signal

order_paid = Signal()  # providing_args deprecated in 4.0+

# In a view/service after payment
order_paid.send(sender=Order, order=order, amount=order.total)

# Receiver
@receiver(order_paid)
def send_receipt(sender, order, amount, **kwargs):
    EmailService.send_receipt(order, amount)

Transaction-safe side effects

from django.db import transaction
from django.db.models.signals import post_save

@receiver(post_save, sender=Order)
def enqueue_fulfillment(sender, instance, created, **kwargs):
    if not created:
        return
    transaction.on_commit(
        lambda: fulfillment_queue.enqueue(instance.pk)
    )

Async receiver (Django 5.0+)

from asgiref.sync import sync_to_async

@receiver(post_save, sender=Comment)
async def notify_subscribers(sender, instance, **kwargs):
    await broadcast_to_channel(f"post-{instance.post_id}", {
        "event": "new_comment",
        "id": instance.pk,
    })

Robust dispatch with error collection

results = order_paid.send_robust(sender=Order, order=order)
for receiver_fn, response in results:
    if isinstance(response, Exception):
        logger.exception("receiver %s failed", receiver_fn, exc_info=response)

Cache invalidation

from django.core.cache import cache
from django.db.models.signals import post_save, post_delete

@receiver([post_save, post_delete], sender=Article)
def purge_article_cache(sender, instance, **kwargs):
    cache.delete(f"article:{instance.pk}")
    cache.delete_pattern("articles:list:*")  # if django-redis

Disconnect for testing

import pytest
from django.db.models.signals import post_save
from myapp.signals import create_user_profile

@pytest.fixture(autouse=True)
def _silence_profile_signal():
    post_save.disconnect(create_user_profile, sender=User)
    yield
    post_save.connect(create_user_profile, sender=User)

매 결정 기준

상황	Approach
Cross-app decouple side-effect	Signal ✅
Same-app, deterministic flow	Direct method call (signal 불필요)
Heavy work (email, ML inference)	Signal → enqueue Celery/RQ task
Cross-process / cross-service	Kafka/RabbitMQ — 매 signal 은 in-process 만
Need ordering / replay	Outbox pattern + message broker

기본값: signal 은 light decouple 만, heavy work 는 즉시 task queue 의 enqueue.

🔗 Graph

• 부모: Observer-Pattern
• 변형: Django Signals · (blinker)

🤖 LLM 활용

언제: in-process decoupling 이 필요할 때, ORM lifecycle hook (post_save 등) 이 자연스러울 때, 매 third-party app 의 own model 의 alter 못할 때. 언제 X: cross-service eventing — 매 Kafka/Outbox 의 use; complex workflow orchestration — 매 Celery chain / Temporal 의 use; testability 가 critical 한 critical path — 매 explicit service call 의 prefer.

❌ 안티패턴

• Heavy work in receiver: 매 sync send 면 request latency 의 block — Celery enqueue.
• Signals for in-app flow: 매 traceability 의 lose — 매 explicit method call 의 use.
• No transaction.on_commit: post_save 시점 의 transaction 미commit — race condition 발생.
• Forgetting weak=False: lambda receiver 가 GC 의 collected — 매 module-level def 또는 weak=False.
• Test pollution: signal 의 test 사이 의 leak — fixture 의 disconnect.

🧪 검증 / 중복

• Verified (docs.djangoproject.com/en/5.1/topics/signals/, Django source dispatch/dispatcher.py).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — Django 5.1 signal patterns + async receiver + transaction.on_commit