Building Internal Events in Django Without Kafka or RabbitMQ

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:

• Decoupling
• Flexibility
• Cleaner business logic

Without operational overhead. And sometimes, that's what a growing system needs.