In der Fintech-Landschaft des Jahres 2026 ist die Erwartung der Nutzer Unmittelbarkeit. Es ist nicht mehr akzeptabel, tagelang auf ein vorläufiges Feedback zu einer Finanzierungsanfrage zu warten. Hier kommt die Event-Driven Architecture: Echtzeit-Verwaltung der Antragsbearbeitung ins Spiel, ein Paradigma, das monolithische und langsame Bankprozesse in reaktive und skalierbare Datenströme verwandelt. Dieser technische Artikel untersucht, wie man ein verteiltes System entwickelt, das den Lebenszyklus einer Hypothek verwalten kann und dabei Resilienz sowie Datenkonsistenz gewährleistet.

1. Das Problem: Grenzen von Request/Response-Architekturen bei Hypotheken

Traditionell erfolgte die Orchestrierung eines Hypothekenantrags über monolithische Architekturen oder Microservices, die über HTTP (REST/gRPC) gekoppelt waren. Dieser Ansatz weist strukturelle Schwachstellen auf:

• Zeitliche Kopplung: Wenn der Credit Scoring-Dienst langsam ist, blockiert der gesamte Antragsprozess und lässt den Nutzer vor einem Ladesymbol warten.
• Ineffizientes Polling: Downstream-Systeme müssen die zentrale Datenbank ständig abfragen, um zu wissen, ob neue Anträge zur Bearbeitung vorliegen («Sind wir schon da?»), was Rechenressourcen verschwendet.
• Fehlerbehandlung: In einer Kette synchroner Aufrufe kann der Ausfall eines peripheren Dienstes (z. B. des PDF-Generators) die gesamte Transaktion scheitern lassen.

2. Die Lösung: Event-Driven Architecture (EDA)

In einer ereignisgesteuerten Architektur kommunizieren Microservices nicht direkt miteinander. Stattdessen produzieren und konsumieren sie Events (Ereignisse). Ein Event ist eine unveränderliche Tatsache, die in der Vergangenheit stattgefunden hat (z. B. MortgageApplicationSubmitted).

Schlüsselkomponenten der Architektur

Für unseren Anwendungsfall vergleichen wir zwei dominierende technologische Backbones:

• Apache Kafka: Ideal für hohen Durchsatz und wenn Log Retention erforderlich ist, um Events erneut zu verarbeiten (Replayability). Es ist die bevorzugte Wahl für Banken, die einen unveränderlichen Audit-Trail On-Premise oder hybrid benötigen.
• Amazon EventBridge: Eine Serverless-Lösung, perfekt für das intelligente Routing von Events in der AWS-Cloud. Sie reduziert den operativen Aufwand, hat aber im Vergleich zu Kafka Grenzen bei der Payload-Größe und der Retention.

Architekturentscheidung: Für ein komplexes Hypothekensystem, das Historisierung und strenge Audits erfordert, verwenden wir Apache Kafka als zentralen Event Bus und integrieren Schema Registry-Muster (z. B. Avro oder Protobuf), um die Kompatibilität der Datenverträge zu gewährleisten.

3. Gestaltung des Ablaufs: Choreografie vs. Orchestrierung

Die Verwaltung eines Hypothekenantrags ist ein Long-Running Process (langlaufender Prozess). Wir müssen entscheiden, wie wir die Dienste koordinieren:

Beteiligte Microservices

1. Application Service: Empfängt die Anfrage vom Nutzer.
2. Scoring Service: Bewertet das Kreditrisiko (Schufa, Experian).
3. Document Service: Verwaltet Upload und OCR-Validierung der Dokumente.
4. Bank Gateway: Kommuniziert mit den Legacy-Systemen der Bank für den endgültigen Beschluss.
5. Notification Service: Sendet E-Mail/SMS/Push an den Nutzer.

Wir verwenden einen hybriden Ansatz: Choreografie für Status-Events (Pub/Sub) und Orchestrierung (über das Saga-Pattern) für das Management der transaktionalen Konsistenz.

4. Management der Konsistenz: Das Saga-Pattern

In einem verteilten System können wir keine ACID-Transaktionen der lokalen Datenbank für Prozesse verwenden, die mehrere Dienste durchlaufen. Wir müssen die Eventual Consistency akzeptieren. Aber was passiert, wenn das Bank Gateway den Antrag ablehnt, nachdem der Scoring Service ihn genehmigt hatte?

Wir müssen das Saga-Pattern implementieren, um Rollbacks (kompensierende Transaktionen) zu verwalten.

Beispiel eines Saga-Ablaufs (Choreografie)

Stellen wir uns den erfolgreichen Ablauf und den Fehlerfall vor:

Schritt 1: Transaktionsbeginn

Der Nutzer sendet die Anfrage. Der Application Service veröffentlicht das Event:

{
  "eventId": "uuid-1234",
  "eventType": "MortgageApplicationSubmitted",
  "payload": {
    "applicationId": "M-999",
    "amount": 200000,
    "applicant": "Mario Rossi"
  }
}

Schritt 2: Parallele Verarbeitung

Der Scoring Service und der Document Service hören auf das Event. Der Scoring Service genehmigt und veröffentlicht CreditScoreApproved. Der Document Service validiert die PDFs und veröffentlicht DocumentsValidated.

Schritt 3: Aggregation und Entscheidung

Das Bank Gateway wartet auf beide Events. Sobald diese empfangen wurden, versucht es, den Antrag auf dem Bank-Mainframe zu finalisieren.

Schritt 4: Fehler und Kompensation (Rollback)

Wenn der Mainframe mit einem Fehler antwortet (z. B. «Unzureichende Deckung» oder «Timeout»), veröffentlicht das Bank Gateway das Event MortgageFinalizationFailed.

An diesem Punkt greifen die Compensating Transactions:

• Der Scoring Service hört auf den Fehler und gibt eventuelle «Locks» auf das Kreditrating des Nutzers frei.
• Der Application Service hört auf den Fehler und aktualisiert den Status des Antrags von «In Bearbeitung» auf «Abgelehnt» und benachrichtigt den Nutzer.

5. Technische Details und Best Practices

Idempotenz

In Kafka ist die Exactly-once-Zustellung komplex. Es ist sicherer, die Consumer so zu gestalten, dass sie idempotent sind. Wenn der Notification Service das Event MortgageApproved zweimal empfängt, muss er (anhand einer eindeutigen Event-ID, die in Redis oder DB gespeichert ist) erkennen können, dass er die E-Mail bereits gesendet hat, und das Duplikat verwerfen.

Dead Letter Queues (DLQ)

Was passiert, wenn ein Event fehlerhaft ist und den Consumer zum Absturz bringt? Wir können die Queue nicht blockieren. Das problematische Event muss nach X fehlgeschlagenen Versuchen in eine Dead Letter Queue verschoben werden, damit das Engineering-Team es manuell analysieren kann, ohne den Fluss der anderen Anträge zu stoppen.

Schema-Evolution

Hypothekenanträge ändern sich im Laufe der Zeit (neue Vorschriften, neue Datenfelder). Die Verwendung einer Schema Registry ist grundlegend. Producer und Consumer müssen sich auf das Schema einigen (z. B. Avro). Wenn wir das Feld vorzugszinssatz hinzufügen, dürfen die alten Consumer nicht kaputtgehen (Backward Compatibility).

6. Implementierung: Konfigurations-Snippet Kafka (Java/Spring Boot)

Hier ist ein Beispiel, wie man einen Consumer konfiguriert, der das Transaktionsmanagement in einem Spring Cloud Stream-Kontext unterstützt:

@Bean
public Consumer<MortgageEvent> mortgageProcessor() {
    return event -> {
        if (event.getType().equals("MortgageApplicationSubmitted")) {
            try {
                scoringService.calculate(event.getPayload());
            } catch (Exception e) {
                // Logik zum Senden an DLQ oder automatischer Retry
                throw new AmqpRejectAndDontRequeueException(e);
            }
        }
    };
}

7. Fazit

Der Übergang zu einer Event-Architektur für das Hypothekenmanagement ist nicht nur eine technologische Stilübung, sondern eine geschäftliche Notwendigkeit. Sie ermöglicht es, Entwicklungsteams zu entkoppeln (das Team «Dokumente» kann Updates veröffentlichen, ohne sich mit dem Team «Bank» abzustimmen), Dienste unabhängig zu skalieren (mehr Ressourcen für das Scoring während Antragsspitzen) und dem Endnutzer eine flüssige und transparente Erfahrung zu bieten.

Die Komplexität, die durch das Management der Eventual Consistency und der Kompensationsmuster eingeführt wird, ist der Preis für ein resilientes System, das hohe Volumina ohne die Flaschenhälse zentralisierter relationaler Datenbanken bewältigen kann.

Häufig gestellte Fragen