Azure Service Bus vs Event Hubs — Messaging Choice for Java

Azure Service Bus and Event Hub both move messages between services, but they serve fundamentally different consumption models — Service Bus is a message broker for transactional workloads; Event Hub is an event stream for high-throughput ingestion.

Service Bus — transactional message broker

• Service Bus delivers a message to exactly one consumer from a queue — when the consumer reads a message and calls complete(), it's removed; if the consumer fails and calls abandon() or the lock expires, it becomes visible again for reprocessing
• Topics and subscriptions extend this with fan-out: one message published to a topic can be delivered to multiple subscriptions, each with its own filter and dead-letter queue
• Service Bus supports message sessions (ordered processing per entity), deferred messages, scheduled delivery, and dead-letter queues for unprocessable messages — which makes it the right choice for order processing, payment workflows, and any use case where each message must be processed exactly once with retry

Event Hub — high-throughput event stream

• Event Hub stores events in partitioned ordered logs — multiple consumer groups can independently read the same stream from different offsets, which means one stream of telemetry events can be consumed independently by a metrics aggregator, a real-time dashboard, and a cold storage archiver
• Events are retained for a configurable period (1-7 days by default, up to 90 days with Event Hub Premium) — which means consumers can replay events without the producer knowing or caring
• Event Hub supports Kafka protocol — existing Kafka producers and consumers can connect to Event Hub with only a connection string change, which makes it a managed Kafka alternative on Azure

Spring integration

• Spring Cloud Azure provides spring-cloud-azure-starter-servicebus with ServiceBusSenderClient and listener annotations; spring-cloud-azure-starter-eventhubs wraps Event Hub with reactive and batch consumers