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.
SOCIAL SHARE CARD GENERATOR