DEV Community: seyedali moradi (call me Sam)

Building Internal Events in Django Without Kafka or RabbitMQ

seyedali moradi (call me Sam) — Fri, 26 Jun 2026 08:48:53 +0000

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:

Decoupling
Flexibility
Cleaner business logic Without operational overhead.

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

Move to Event-Driven Architecture

seyedali moradi (call me Sam) — Fri, 19 Jun 2026 13:26:28 +0000

Like many teams we didn’t choose event-driven architecture in the first place.

At first, the application was relatively simple. A user performed an action, the backend processed it, updated the database, and returned a response.

But as the product evolved new requirements showed up!

A single action didn’t just affect one part of the system.

Creating or updating data could trigger:

Price recalculations
Cache invalidations
Real-time frontend updates
Audit logging
Notifications
Reporting updates

Initially, these responsibilities were handled directly inside service methods.
A simplified example looked something like this:

def update_price(data):

 price = calculate_price(data)

 save(price)

 update_cache(price)

 create_audit_log(price)

 realtime_update(price)

 update_reports(price)

At first this approach seemed to work.

But over time problems grew.

The Cost of Coupling
Every new requirement meant modifying existing code.

Even a simple business change may require changing multiple services.

The result was:
Larger service functions and methods
More dependencies that became impossible to maintain over time
More testing complexity that eventually became unmanageable
Higher risk during deployment
Unexpected behavior during edge cases

The Real-Time Challenge
The biggest challenge appeared when we introduced more real-time functionality.

Frontend clients needed immediate updates whenever important data changed.

Users needed immediate updates whenever important data or data related to them changed.

A Different Perspective
So instead of asking which services need to be called, we start to ask what happened?

And rather than directly invoking downstream processes, we introduced events.

Services no longer needed to know who was interested in those events.

They simply published them.

Consumers could subscribe and react independently.

What Changed
Instead of this:

Service A

├─ Service B

├─ Service C

└─ Service D

We moved toward:

Service A

│

▼

Event Bus

│

├─ Consumer B

├─ Consumer C

└─ Consumer D

The producer became responsible only for publishing an event.

Consumers became responsible for their own behavior.

This significantly reduced coupling between components.

Benefits We Observed
Easier Feature Development
Adding new features often means a new event consumer rather than modifying existing business logic.

Better Separation of Concerns
Services focused on their responsibilities instead of coordinating multiple downstream processes.

Improved Real-Time Updates
Frontend updates became event-driven rather than tightly integrated into backend workflows.

What We Learned
Moving to an event-driven architecture did not eliminate complexity.

It changed where the complexity lived.

We had to think about:

Event contracts
Idempotency
Ordering
Delivery guarantees

However, these challenges were easier to manage rather than dependencies we had before.

The architecture change gave us a system that could evolve without requiring every component to know about every other one.

And as the application grew, that flexibility became one of the most valuable decisions we made.

Have you made the move to event-driven architecture? What were your challenges and how to solve them?