Ereignisgesteuerte Architektur: Wie wir einen 50.000 Dollar pro Monat teuren Monolithen ersetzt haben

Das Problem: Ein Monolith, der nicht skalierbar war

Zuvor: Die synchrone Kette des Schmerzes

# Die alte Methode: alles synchron, alles miteinander 
verknüpftdef process_order(request):
    order = Order.objects.create(**request.data)    

 # Wenn auch nur einer dieser Schritte fehlschlägt, schlägt die Bestellung fehl
    inventory_service.reserve(order)        # 200 ms
    payment_service.charge(order)           # 800 ms
    email_service.send_confirmation(order)  # 500 ms
    analytics_service.track(order)          # 300 ms
    warehouse_service.notify(order)         # 400 ms    

 # Gesamt: Mindestens 2200 ms Reaktionszeit
    # Wenn der E-Mail-Dienst ausfällt: Bestellung schlägt fehl
    # Wenn die Analyse langsam ist: Checkout ist langsam
    return Response({'order_id': order.id})

Die Architektur: Ereignisse + Befehle

Danach: Ereignisgesteuert mit Celery + Redis

# Der neue Ansatz: Synchron für den kritischen Pfad, Ereignisse für den 
Rest def process_order(request):    
 order = Order.objects.create(**request.data)    

 # Kritischer Pfad: muss erfolgreich sein (synchron)    
 inventory_service.reserve(order)   # 200 ms    
 payment_service.charge(order)      # 800 ms    

 # Ereignis veröffentlichen: „Fire-and-Forget“ (async)
    publish_event('order.completed', {
        'order_id': order.id,
        'customer_email': order.customer.email,
        'total': str(order.total),
    })    

 # Insgesamt: 1000 ms Antwortzeit
    # E-Mail ausgefallen? Bestellung wird trotzdem erfolgreich abgeschlossen. Später erneut versucht.
    return Response({'order_id': order.id})


# Ereignis-Handler (separate Worker)
@celery_app.task(bind=True, max_retries=5, default_retry_delay=60)
def handle_order_completed(self, event_data):
    """Jeder Handler ist unabhängig und kann erneut versucht werden"""
    try:
        email_service.send_confirmation(event_data)
    except Exception as exc:
        self.retry(exc=exc, countdown=2 ** self.request.retries * 60)

Das Event-Bus-Muster

import redisimport
 
jsonfrom datetime import 

datetimeclass EventBus:
    def __init__(self):
        self.redis = redis.Redis(host='redis', port=6379, db=0)    

 def publish(self, event_type: str, data: dict):
        """Ereignis an Redis Stream senden"""
        event = {
            'type': event_type,
            'data': json.dumps(data),
            'timestamp': datetime.utcnow().isoformat(),
        }
        self.redis.xadd(f'events:{event_type}', event)    

 def subscribe(self, event_type: str, group: str, consumer: str):
        """Ereignisse mit einer Verbrauchergruppe lesen (jedes Ereignis wird einmal verarbeitet)"""
        try:
            self.redis.xgroup_create(
                f'events:{event_type}', group, id='0', mkstream=True
            )
        except redis.ResponseError:
            pass  # Gruppe existiert bereits        

 while True:
            events = self.redis.xreadgroup(
                group, consumer,
                {f'events:{event_type}': '>'},
                count=10, block=5000
            )
            for stream, messages in events:
                for msg_id, fields in messages:
                    yield msg_id, json.loads(fields[b'data'])
                    self.redis.xack(stream, group, msg_id)

Ergebnisse nach 3 Monaten

Wann man keine ereignisgesteuerte Architektur verwenden sollte

Fang mit einem Monolithen an. Löse die Systemkomponenten auf, wenn du Probleme bekommst. Die schlechteste Architektur ist die, die für Probleme entwickelt wurde, die du noch gar nicht hast.

— alokknight Engineering