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 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. 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.