Kafka 또는 RabbitMQ 없이 Django에서 내부 이벤트 만들기

When we hear about event driven architecture, we usually jump into tools like Kafka or RabbitMQ.

But in practice, most backend systems don’t need distributed messaging infrastructure at first.
What is needed is something much simpler:
A way to decouple business logic inside a single application.
This is where internal events will help us.

The Problem: Tight Coupling in Django Services

When a Django application grows, service methods tend to accumulate responsibilities.
A single business action triggers multiple side effects:

• Updating database records
• Invalidating cache
• Sending notifications
• Writing audit logs

At first, this looks manageable:

def update_order(order_data):
    order = save_order(order_data)
    update_cache(order)
    send_notification(order)
    write_audit_log(order)
    return order

Enter fullscreen mode Exit fullscreen mode

But over time, this pattern becomes painful:

• Every new requirement modifies core logic
• Testing becomes harder
• Side effects are tightly coupled
• Business logic is buried under orchestration code The real issue is not complexity itself — it’s dependency direction.

Introducing Internal Events (No Kafka Required)

To solve this problem we implemented a simple internal event system inside Django.
No external infrastructure needed.
No message broker.

Step 1: Define Event Types
We defined events as simple objects like this:

class OrderCreatedEvent:
    def __init__(self, order_id, user_id):
        self.order_id = order_id
        self.user_id = user_id

Enter fullscreen mode Exit fullscreen mode

Step 2: Create an Event Bus
A basic in-memory dispatcher:

from collections import defaultdict

class EventBus:
    def __init__(self):
        self._handlers = defaultdict(list)

    def subscribe(self, event_type, handler):
        self._handlers[event_type].append(handler)

    def publish(self, event):
        event_type = type(event)
        for handler in self._handlers[event_type]:
            handler(event)

Enter fullscreen mode Exit fullscreen mode

Step 3: Define Handlers (Consumers)
Each side effect becomes its own handler:

def update_cache(event):
    pass


def send_notification(event):
    pass


def write_audit_log(event):
    pass

Enter fullscreen mode Exit fullscreen mode

Step 4: Wire Everything Together

event_bus = EventBus()
event_bus.subscribe(OrderCreatedEvent, update_cache)
event_bus.subscribe(OrderCreatedEvent, send_notification)
event_bus.subscribe(OrderCreatedEvent, write_audit_log)

Enter fullscreen mode Exit fullscreen mode

Step 5: Publish Events From Business Logic
Now business logic becomes much cleaner:

def create_order(order_data):
    order = save_order(order_data)

    event_bus.publish(
        OrderCreatedEvent(order.id, order.user_id)
    )

    return order

Enter fullscreen mode Exit fullscreen mode

What Changed?
So there is no complexity removing, instead we moved:
Before:

• Business logic + side effects mixed together
• Hard to extend without modifying core code

After:

• Business logic focuses on what happened
• Side effects are independent handlers

Why This Work:
We didn’t need:

• Distributed messaging
• Broker infrastructure
• Event persistence
• Network reliability guarantees

Because our scope was a single Django system.
Internal events are enough when:

• You are inside a monolith
• You want decoupling, not distribution
• You want testable side effects
• You want flexibility without infrastructure overhead

Important Limitations
This approach is not a replacement for Kafka or RabbitMQ.
It doesn’t give you:

• Persistence of events
• Cross-service communication
• Guaranteed delivery
• Fault tolerance across machines

It is purely in-process. That’s the tradeoff.

When You Eventually Outgrow It
At some point, you may need:

• Async processing
• Distributed consumers
• Event replay
• High reliability guarantees

That’s when tools like Celery, RabbitMQ, or Kafka become relevant.
But the internal event model still helps because:
The architecture is already event-shaped.
So migration becomes easier.
And definitely helps you ship faster.

Finally
Many problems can be solved by changing structure, not adding tools.
Internal events are one of those cases.
They give you:

• Decoupling
• Flexibility
• Cleaner business logic Without operational overhead.

And sometimes, that’s what a growing system needs.