Building Internal Events in Django Without Kafka or RabbitMQ

#eventdriven #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

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

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)

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

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)

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

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: