Message-Broker im Vergleich
| Broker | Modell | Stärken | Schwächen |
|---|
| Kafka | Log-basiert, hochskaliert | Massive Durchsätze (Mio msg/s), Replay, Ordering pro Partition | Komplex zu betreiben, JVM, Zookeeper/KRaft |
| RabbitMQ | Klassische Message-Queue | Flexibles Routing (Topic-Exchanges), AMQP-Standard, einfach | Schlechter bei sehr hohen Volumen als Kafka |
| NATS | Lightweight Pub/Sub | Sehr schnell, klein, niedriger Memory-Footprint, JetStream für Persistence | Weniger Features als Kafka, kleineres Ökosystem |
| AWS SQS / SNS | Managed | Serverless, kein Ops, gute AWS-Integration | Vendor-Lock, höhere Latenz, Order schwierig |
| Redis Streams | In-Memory | Sehr niedrige Latenz, einfach wenn Redis schon da | Nicht für Long-Term-Storage gedacht |
Delivery-Semantik
- At-most-once: Event kommt 0 oder 1 mal an. Verluste möglich.
- At-least-once: Event kommt 1 oder mehrere Male an. Subscriber muss idempotent sein. Standard.
- Exactly-once: Heiliger Gral. Sehr schwer. Kafka bietet es per Transactional Producer + Consumer Offset Commit.
Idempotenz-Pattern
function handleEvent(event) {
if (db.has('processed', event.id)) return; // schon verarbeitet
db.transaction(() => {
doWork(event);
db.insert('processed', event.id);
});
}
Zurück zu Technik