* added new microservice pattern polling-publisher, created folder structure, README.md & App.java * added two service polling service & publisher service to handle two different operation & prepared initial skeleton * polling-publisher service implementation * fixed checkstyle errors * subscriber-service implementation * added entry point for subscriber service & unit test-case * added unit test-case for DataSourceService class * resolved dependency & structured classes * implemented Data repository, DataSource Service & added unittest-case & implemented polling-service microservice * implemented subscriber microservice using kafkaConsumer * Fixed Kafka bug & added a controller to send message using API * Fixed subscriber-service & updated pom.xml * Fixed topic name * added new listener for other topic * updated all README.md * added description on both application.yaml file * added scope before class definition in Test classes & removed duplicate dependency from pom.xml & added required one * added polling-publisher module in pom.xml * Updated README.md file based on new template * improved the README.md file & fixed it's format * deleted unnecessary README.md files * fixed the printing statements & used log function * used logger to print statement * addressed review comment: removed unnecessary dependency * addressed review comment
4.1 KiB
title, shortTitle, description, category, language, tag
| title | shortTitle | description | category | language | tag | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Polling Publisher-Subscriber Pattern in Java: Mastering Asynchronous Messaging Elegantly | Polling Pub/Sub | Learn how to implement a Polling Publisher-Subscriber system in Java using Spring Boot and Kafka. Explore the architecture, real-world analogies, and benefits of asynchronous communication with clean code examples. | Architectural | en |
|
Also known as
- Event-Driven Architecture
- Asynchronous Pub/Sub Pattern
- Message Queue-Based Polling System
Intent of Polling Publisher-Subscriber Pattern
The Polling Publisher-Subscriber pattern decouples data producers from consumers by enabling asynchronous, message-driven communication. A service polls a data source and publishes messages to a message broker (e.g., Kafka), which are then consumed by one or more subscriber services.
Detailed Explanation of the Pattern with Real-World Examples
Real-world analogy
A news agency constantly polls for the latest news updates. Once it receives new information, it publishes them to different news outlets (TV, newspapers, apps). Each outlet consumes and displays the updates independently.
In plain words
One service regularly checks for updates (polls) and sends messages to Kafka. Another service listens to Kafka and processes the messages asynchronously.
Wikipedia says
This pattern closely resembles the Publish–subscribe model, where messages are sent by publishers and received by subscribers without them knowing each other.
Architecture Flow
+------------+ +--------+ +-------------+
| Publisher | ---> | Kafka | ---> | Subscriber |
+------------+ +--------+ +-------------+
Programmatic Example (Spring Boot + Kafka)
Publisher Service
- Uses Spring's
@Scheduledto poll data periodically. - Publishes data to a Kafka topic.
- Optionally exposes a REST API for manual data publishing.
@Scheduled(fixedRate = 5000)
public void pollAndPublish() {
String data = pollingService.getLatestData();
kafkaTemplate.send("updates-topic", data);
}
Subscriber Service
- Listens to Kafka topic using
@KafkaListener. - Processes messages asynchronously.
@KafkaListener(topics = "updates-topic")
public void processUpdate(String message) {
log.info("Received update: {}", message);
updateProcessor.handle(message);
}
When to Use the Polling Publisher-Subscriber Pattern
Use this pattern when:
- Real-time push from the producer is not possible.
- Loose coupling between producers and consumers is desired.
- You need asynchronous, scalable event processing.
- You are building an event-driven microservices architecture.
Real-World Applications
- Real-time reporting dashboards
- Health check aggregators for distributed systems
- IoT telemetry processing
- Notification and alerting systems
Benefits and Trade-offs of Polling Pub/Sub Pattern
Benefits
- Loose coupling between services
- Asynchronous and scalable architecture
- Fault-tolerant with message persistence in Kafka
- Easy to extend with new consumers or publishers
Trade-Offs
- Polling introduces latency between data generation and consumption
- Requires managing and configuring Kafka (or other brokers)
- Slightly more complex deployment and infrastructure setup