Event-Bus Architektur: Pipeline-Schritte über Pub/Sub entkoppeln #29

New issue

Open

opened 2026-03-30 19:47:52 +00:00 by David · 0 comments

David commented

2026-03-30 19:47:52 +00:00

Collaborator

Beschreibung

Die direkte Funktionsaufruf-Kette der Pipeline durch ein internes Event-Bus-System (Publish/Subscribe) ersetzen, um parallele Verarbeitung, einfache Erweiterbarkeit und bessere Observability zu ermöglichen.

Hintergrund

Die aktuelle Pipeline ist eine lineare Kette direkter Funktionsaufrufe (poll → score → prepare → run → MR). Das macht es schwer, neue Stages einzufügen, unabhängige Tickets parallel zu verarbeiten oder einzelne Stages isoliert zu testen. OpenAIs Codex "Triggers" und Google's Multi-Agent Design Patterns (2026) zeigen, dass Event-Driven Architecture der Standard für AI-Agent-Systeme ist.

Akzeptanzkriterien

Interner EventBus mit Publish/Subscribe Pattern implementiert
Pipeline-Stages kommunizieren über Events statt direkter Funktionsaufrufe
Events: ticket.new, ticket.scored, ticket.prepared, ticket.code_ready, ticket.review_passed, ticket.mr_created, ticket.failed
Jedes Event wird automatisch geloggt (Observability)
Neue Pipeline-Stages können durch Registrierung eines Event-Handlers hinzugefügt werden
Bestehende Funktionalität bleibt identisch (Refactoring, keine Feature-Änderung)
Mehrere Tickets können parallel verarbeitet werden (konfigurierbare Concurrency)

Technische Hinweise

Neuer Core: backend/events.py — AsyncEventBus mit emit() und on() Decorator
Refactoring: backend/services/pipeline.py — Event-Handler statt direkter Aufrufe
Erweitern: backend/config.py — PIPELINE_MAX_CONCURRENCY
Anfangs: asyncio-basiert. Später optional Redis Streams für Production-Scale
Migration nötig: nein

Aufwand: M

## Beschreibung Die direkte Funktionsaufruf-Kette der Pipeline durch ein internes Event-Bus-System (Publish/Subscribe) ersetzen, um parallele Verarbeitung, einfache Erweiterbarkeit und bessere Observability zu ermöglichen. ## Hintergrund Die aktuelle Pipeline ist eine lineare Kette direkter Funktionsaufrufe (poll → score → prepare → run → MR). Das macht es schwer, neue Stages einzufügen, unabhängige Tickets parallel zu verarbeiten oder einzelne Stages isoliert zu testen. OpenAIs Codex "Triggers" und Google's Multi-Agent Design Patterns (2026) zeigen, dass Event-Driven Architecture der Standard für AI-Agent-Systeme ist. ## Akzeptanzkriterien - [ ] Interner EventBus mit Publish/Subscribe Pattern implementiert - [ ] Pipeline-Stages kommunizieren über Events statt direkter Funktionsaufrufe - [ ] Events: `ticket.new`, `ticket.scored`, `ticket.prepared`, `ticket.code_ready`, `ticket.review_passed`, `ticket.mr_created`, `ticket.failed` - [ ] Jedes Event wird automatisch geloggt (Observability) - [ ] Neue Pipeline-Stages können durch Registrierung eines Event-Handlers hinzugefügt werden - [ ] Bestehende Funktionalität bleibt identisch (Refactoring, keine Feature-Änderung) - [ ] Mehrere Tickets können parallel verarbeitet werden (konfigurierbare Concurrency) ## Technische Hinweise - Neuer Core: `backend/events.py` — AsyncEventBus mit `emit()` und `on()` Decorator - Refactoring: `backend/services/pipeline.py` — Event-Handler statt direkter Aufrufe - Erweitern: `backend/config.py` — `PIPELINE_MAX_CONCURRENCY` - Anfangs: asyncio-basiert. Später optional Redis Streams für Production-Scale - Migration nötig: nein ## Aufwand: M