Messaging Workflows: JMS, Kafka & Outbox

Messaging macht Systeme lose gekoppelt, aber nur mit klaren Verträgen, Idempotenz und Beobachtbarkeit robust.

JMSKafkaOutboxIdempotenz

In dieser Datei

Arten
Event Design
Outbox
Consumer
Fehler
Vergleich

Messaging mit Outbox, Broker und idempotenten Consumern

Arten

Modell	Typisch	Eigenschaft
JMS Queue	Command/Work Queue	Ein Consumer verarbeitet
JMS Topic	Publish/Subscribe	Mehrere Subscriber
Kafka Topic	Event Stream	Partitionen, Offset, Replay
Outbox Table	Zuverlässige Publikation	DB und Event konsistent

Event Design

Events brauchen fachlichen Namen, Version, Zeit, Korrelation und Idempotency Key. Technische Payloads ohne Kontext sind schwer wartbar.

Versioniertes Event

public record OrderPlacedEventV1(
        String eventId,
        String traceId,
        String orderId,
        String customerId,
        Instant occurredAt,
        List<Line> lines) implements DomainEvent {}

Outbox

Outbox ist der Default, wenn ein DB-Zustand und ein Event zusammengehören. Direct publish im Use Case ist fast immer riskanter.

Consumer

Idempotent Consumer

public final class BillingOrderPlacedConsumer { // Pattern: Idempotent Consumer
    public void handle(OrderPlacedEventV1 event) {
        if (processedEvents.alreadyProcessed(event.eventId())) return;
        billing.createDraftInvoice(event.orderId(), event.customerId());
        processedEvents.markProcessed(event.eventId());
    }
}

Fehler

Fehlerstrategie: Retry für temporäre Fehler, Dead Letter Queue für nicht verarbeitbare Nachrichten, Alerting bei wachsendem Lag.

Vergleich

Kriterium	JMS	Kafka
Klassische Enterprise Integration	Sehr stark	Möglich, aber anderes Modell
Replay historischer Events	Begrenzt	Stark
Ordering	Queue/Session-basiert	Partition-basiert
Cloud-native Streams	Mittel	Sehr stark