I Built a Real-Time Product Recall Detection System in One Day with Java, Kafka, and Confluent Cloud

Adarsh Kurumali — Wed, 23 Sep 2026 17:55:26 +0000

What a one-day project taught me about event-driven systems, matching events that arrive out of order, and the difference between a working prototype and a production-ready application.

Imagine buying a product today and learning tomorrow that its manufacturer has recalled a particular batch.

The retailer now has a question to answer:

Which customers purchased that exact batch?

It sounds like a database query. And for some systems, a database query may be an entirely reasonable solution.

But I wanted to explore a different approach:

what if purchases and recall announcements were treated as events, and a service continuously connected them as they arrived?

That question became RecallRadar, a real-time product recall detection prototype I built for Confluent AI Developer Day.

Using Java, Confluent Cloud Kafka, Apache Flink SQL, and Spring Boot, I went from an idea to a working application in one day. It publishes simulated purchase and recall events, identifies affected customers, generates safety alert events, and displays the results on a live dashboard.

The interesting part wasn't simply getting the technologies to communicate. It was discovering what happens when two related events arrive at different times—and what an application needs to remember to connect them.

RecallRadar's dashboard displaying alerts generated from simulated retail events.

The problem: A recall can arrive after the purchase—or before it

Consider two events:

Purchase event

{
  "customerId": "CUST-104",
  "productId": "PRODUCT-42",
  "batchId": "BATCH-7"
}

Recall event

{
  "productId": "PRODUCT-42",
  "batchId": "BATCH-7",
  "reason": "Potential safety issue"
}

These are simplified examples of the event data, not a copy of the project's complete event schema.

The customer is affected because the product and batch identifiers match. Matching only the product identifier would be insufficient: a recall may apply to one manufacturing batch rather than every unit of a product.

Now consider the order in which these events might arrive:

Scenario A — Purchase first: A customer buys the product. Days later, the manufacturer announces a recall.

Scenario B — Recall first: A recall is already known, but a purchase event arrives afterward. This might represent a delayed transaction record or a purchase that requires investigation.

Both scenarios matter. A service that checks only new recalls against previously seen purchases misses one direction of the problem.

That leads to the central design lesson of this project:

When related events can arrive in either order, processing the latest event is not enough. The system also needs access to relevant earlier information.

The architecture I built

RecallRadar uses four Kafka topics:

Topic	Purpose
rr-purchases	Simulated Retail Purchase Events
rr-recalls	Product recall announcements
rr-alerts	Customer-specific safety alert events
rr-recall-impact	Flink-generated recall impact analytics

Two Java producers publish purchases and recalls to their respective topics.

A Java detection service consumes both streams, matches events using productId and batchId, and publishes customer-specific alerts to rr-alerts.

From there, the application has two paths:

Apache Flink SQL continuously aggregates alerts and writes recall impact results to rr-recall-impact.

Spring Boot consumes individual alert events and serves a web dashboard. In the current prototype, the dashboard calculates its displayed metrics independently; it does not read the Flink output topic.

The event-processing pipeline as shown in Confluent Cloud.

The separation is intentional from a learning perspective: one alert stream can serve different consumers with different needs. The dashboard needs individual alerts, while the analytics pipeline needs aggregate information about recall impact.

Lesson 1: Kafka connects the components without making them one application

My first step was creating a Kafka cluster and topics in Confluent Cloud, then configuring the Java producers and consumers to communicate with them.

Rather than having the recall producer call the detection service directly, it publishes an event. The detection service consumes that event when it is available.

That distinction matters. The producer's responsibility is to publish the fact that a recall was announced. It doesn't need to know how the dashboard works or how recall impact is calculated.

Likewise, the dashboard doesn't need to communicate directly with either producer. It consumes the alert events generated by the detection service.

Kafka is not automatically the right choice for every recall system. A conventional database and scheduled query may be simpler for a small application. Event streaming becomes interesting when multiple systems need to react to new information independently, or when continuous processing is part of the requirement.

For RecallRadar, Kafka gave me a practical way to explore that design.

Lesson 2: Event correlation is a state-management problem

The detection service has to answer two questions:

When a recall arrives, which previously observed purchases match it?
When a purchase arrives, does it match a recall that is already known?

In the prototype, the Java service maintains the information needed for this matching in memory.

Here is a simplified sketch of the matching rule:

record ProductBatch(String productId, String batchId) {}

static boolean matches(
        String purchaseProductId,
        String purchaseBatchId,
        String recallProductId,
        String recallBatchId) {

    return purchaseProductId.equals(recallProductId)
            && purchaseBatchId.equals(recallBatchId);
}

Illustrative Java code showing the matching rule—not a verbatim excerpt from the repository.

The matching condition itself is simple. The harder question is where the application gets the purchase and recall records to compare.

If a recall arrives today, the relevant purchase may have been processed yesterday. If the service has forgotten that purchase, the matching function cannot help.

This is why event correlation is also a state-management problem.

For my one-day prototype, in-memory state was a practical way to get the matching logic working and test both event orders. It also creates an important limitation: restarting the service can lose that state.

A production implementation would need a deliberate strategy for durable state, recovery, retention, and replay. It would also need to prevent duplicate customer alerts if an event is processed again.

The takeaway: Writing a correct comparison function is only one part of stream processing. You must also decide what information the system needs to remember, for how long, and how it recovers that information after a failure.

Lesson 3: An alert event can be useful beyond the dashboard

Once the detection service identifies a match, it publishes a customer-specific safety alert to rr-alerts.

That alert can be consumed by the dashboard, but it can also become the input to a separate analytics pipeline.

I used Apache Flink SQL in Confluent Cloud to continuously calculate recall impact statistics, including the number of distinct affected customers and the total number of alert events.

Those results were written to rr-recall-impact.

This is a useful distinction:

An individual alert answers:

“Which customer may be affected by this recall?”

An aggregate answers:

“How many customers and alert events are associated with this recall?”

They are different questions, even though they originate from the same stream.

Flink SQL let me explore continuous aggregation without building a separate Java service solely to maintain those analytics.

One subtle point: total alert events and distinct affected customers are not necessarily the same number. If a customer has multiple matching purchases or receives more than one alert, the event count can be higher than the distinct-customer count.

That is why metric definitions matter as much as the query producing them.

Lesson 4: Managed infrastructure saves setup time, not debugging time

Confluent Cloud helped me move quickly. I could create Kafka topics, inspect messages, register a JSON Schema for alerts, and work with Flink SQL through its cloud interface rather than setting up every component locally.

That made a one-day prototype achievable for me.

It did not mean every step worked on the first attempt.

During development, I encountered a Kafka error along the lines of:

Topic rr-purchases not present in metadata after 60000 ms

That message is a useful reminder that application code is only one part of a distributed system. Topic availability, client configuration, credentials, connectivity, and permissions all need to line up before a producer can successfully publish.

I worked through the configuration and verified successful event publishing before moving on to the detection logic.

The experience changed how I think about debugging: when an event-driven application appears to do nothing, start by checking where the event stopped moving.

Can the producer publish? Is the event visible in the topic? Is the consumer receiving it? Did the detection logic find a match? Was an alert published? Did the dashboard consume it?

Following the event through the pipeline is much more useful than treating the entire application as one black box.

What the finished prototype demonstrates—and what it doesn't

By the end of the day, RecallRadar could process simulated purchase and recall events, generate matching customer alerts, maintain recall impact analytics through Flink SQL, and display live alert information in a Spring Boot dashboard.

Watch the Live Demo to RecallRadar

Demo: publishing events and observing the resulting alerts in the running application.

But “working” and “production-ready” are not synonyms.

RecallRadar currently uses simulated transactions and fictional recalls. Its detection service maintains matching state in memory. It generates alert events but does not deliver real emails or SMS messages to customers. Its dashboard consumes the alert stream independently of the Flink-generated analytics topic.

Before using a system like this for actual consumer safety decisions, I would want to address durable state, recovery after restarts, duplicate-alert prevention, verified recall data, auditability, and reliable customer notification delivery.

Those are not small finishing touches. They are part of the core design of a dependable system.

The most useful thing I learned

I started this project thinking about Kafka topics, Java consumers, and a live dashboard.

I finished it thinking much more about time and memory.

A purchase and a recall can be related even when they arrive hours or days apart. To recognize that relationship, the application must retain—or be able to recover—the right information.

That insight extends beyond product recalls. Similar questions appear in payment reconciliation, fraud detection, order tracking, inventory management, and other systems where an event only becomes meaningful when connected to something that happened earlier.

The technology stack made RecallRadar possible, but this was the lesson I found most valuable:

In an event-driven system, deciding what to remember can be just as important as deciding what to process next.

If you're learning Kafka or stream processing, try building a small application with two related event types. Then test what happens when you reverse their arrival order, restart the consumer, or process the same event twice. Those experiments reveal design questions that a happy-path demo can easily hide.

Explore RecallRadar 👇

The project source code and setup instructions are available on GitHub:

RecallRadar — GitHub repository

This was a one-day hackathon prototype, and I've shut down its Confluent Cloud resources after submission (Of course 😂). The repository remains available for anyone who wants to explore the implementation.

I'd be interested to hear how others would approach durable event correlation and duplicate-alert prevention in a production version of this system.

DEV Community: Adarsh Kurumali

I Built a Real-Time Product Recall Detection System in One Day with Java, Kafka, and Confluent Cloud

Lesson 1: Kafka connects the components without making them one application

Lesson 2: Event correlation is a state-management problem

Lesson 3: An alert event can be useful beyond the dashboard