DEV Community: Prashant Sasalatti

The Trade You Can't Close: Why the Hardest Part of Investing Is You

Prashant Sasalatti — Sat, 20 Jun 2026 09:03:13 +0000

Why the hardest part of investing isn’t the market. It’s the person making the decisions.

Photo by Maxim Hopman on Unsplash

There is a specific moment every trader knows and almost no one talks about.

The stock is down. Not catastrophically — just enough. The reason you bought it hasn’t really changed, but the number on the screen has, and now you’re doing something you didn’t plan to do: you’re negotiating. I’ll sell when it gets back to what I paid. You’re not analyzing anymore. You’re waiting to be made whole, as if the market owes you the price you happened to buy at.

I have sat in that exact moment more times than I’d like to admit. And the uncomfortable truth I eventually had to accept is that the moment isn’t about the stock at all. It’s about me.

The pattern has a name

What I thought was a personal weakness turns out to be one of the most documented behaviors in all of finance. It’s called the disposition effect — the tendency to sell winners too early and hold losers too long.

It isn’t a hunch. Using account data from a large brokerage, researchers found that individual investors are roughly 50 percent more likely to sell a winning position than a losing one, relative to their chances to do so. We lock in gains because they feel good, and we cling to losses because closing them means admitting we were wrong.

Underneath that sits something older and deeper. Kahneman and Tversky called it loss aversion: the pain of losing is psychologically far heavier than the pleasure of an equal gain. A 10,000 loss doesn’t feel like the mirror image of a 10,000 win. It feels worse — so much worse that we’ll take bigger risks just to avoid realizing it. That’s why the losing stock is the one you can’t close. Selling it converts a paper loss, which still feels survivable, into a real one, which feels like a verdict.

Photo by Nicholas Cappello on Unsplash

The expensive part

Here’s the line that rearranged how I think about all of this.

In a landmark study of more than 66,000 households, the investors who traded the most earned an annual return of 11.4 percent, while the market returned 17.9 percent. Same market. Same years. The only variable was activity. The more they traded, the more they fell behind.

The cause the researchers settled on wasn’t bad luck or bad information. It was overconfidence — the quiet, constant belief that this time I’ve read it right, that my conviction is insight rather than noise. Overconfident traders trade more. Trading more costs more and decides worse. The market doesn’t punish stupidity. It punishes certainty.

And it doesn’t spare any of us by geography. Studies of Indian retail investors find the same fingerprints — loss aversion and mental accounting shaping decisions, emotions riding visibly on the P&L. In one survey, traders strongly agreed that losses significantly hit their mood and confidence, and that their sense of self was tied to whether a trade was green or red. The screen stops being a market and becomes a mirror.

What actually changed for me

I didn’t fix this by getting smarter about markets. You can’t out-analyze your own nervous system. What helped was smaller and more boring.

I started writing the exit before the entry — the price I’d sell at if I was wrong — when I was still calm, because the version of me holding a loss cannot be trusted to decide. I started treating the urge to “wait until it gets back to even” as a siren, not a strategy; the market has never once cared what I paid. And I started noticing that the trades I felt most certain about were, suspiciously often, the ones that hurt the most.

The hardest skill in investing isn’t spotting the opportunity. It’s surviving the part where your own brain quietly works against you — and learning to act anyway.

The trade you can’t close is rarely the problem. It’s usually just the place where you finally see yourself clearly.

If you’ve ever held a losing position longer than you should have, you already know the feeling I’m describing. I’d love to hear how you learned to let go — or whether you still struggle with it. The comments are open.

Nothing here is financial advice. It’s just one person’s attempt to understand why smart people make the same expensive mistakes — myself very much included.

The Deadlock That Only Showed Up Under Load: Debugging DB2 SQLCODE -811 in Production

Prashant Sasalatti — Sat, 20 Jun 2026 07:08:09 +0000

A real production incident, what the error actually meant, and the fix that stopped it from happening again.

Photo by Chris Ried on Unsplash

Some bugs are polite. They fail the same way every time, on your machine, with a clean stack trace pointing at the exact line. You fix them before lunch.

This was not one of those bugs.

This one only appeared in production, only under concurrent load, and only sometimes. The error code, DB2 SQLCODE -811, is one of those messages that looks like it's telling you something useful while telling you almost nothing. Here's how we tracked it down on a payroll system processing timecards for a large workforce, and what it taught me about writing code that survives concurrency.

The symptom

The application is a Java EE enterprise system backed by DB2. During peak processing windows, a batch job that reconciled timecard records started throwing:

SQLCODE = -811, SQLSTATE = 21000

Intermittently. Not every run. Not reproducible on demand. The kind of failure that makes you stare at logs at 3 AM wondering if you imagined it.

The job would succeed nine times out of ten. The tenth time, it blew up, and because this was payroll, blowing up one time in ten is not something you get to shrug off.

Two paths writing to the same place. Photo by Jordan Harrison on Unsplash.

What SQLCODE -811 actually means

Here's the part the error message hides. SQLCODE -811 is not a deadlock. It's not a lock timeout. It's this: a subquery, embedded SELECT, or SELECT INTO returned more than one row where the code expected exactly one.

That's it. A scalar context got a non-scalar answer.

So why was it intermittent? Because the duplicate row only existed transiently, during a window where two processes were both writing to the same logical record before either had committed. Under light load, the timing never lined up. Under heavy concurrent load, it did, and a query that assumed uniqueness suddenly found two rows mid-flight.

This is the trap with -811: the error points at the SELECT, but the SELECT isn't the bug. The bug is upstream, in how rows got created in the first place.

Tracking it down

Three things made this findable.

1. Stop trusting that it can't return two rows. The query had a SELECT INTO against a working table, filtered on what everyone assumed was a unique business key. It wasn't enforced as unique at the database level, it was unique by convention. Convention does not survive a race condition. I added logging to dump the offending key and row count at the moment of failure. The next time it fired, the evidence was unambiguous: two rows, identical business key, created milliseconds apart.

2. Find who writes to that table, and when. Two code paths inserted into the same working table. Neither was aware of the other. Both ran during the same processing window. Each one, in isolation, was correct. Together, they produced transient duplicates that a downstream SELECT INTO couldn't handle. This is the thing about concurrency bugs: every individual piece of code can be correct and the system can still be wrong. The defect lives in the gaps between components, not inside any one of them.

3. Reproduce it deliberately. I could not fix what I could not reproduce. So I forced the race: two threads hammering the same key path concurrently against a test database. Within a few runs, -811 appeared on command. Once a heisenbug becomes reproducible, it stops being scary and becomes ordinary work.

The fix

There were three layers to it, in order of how durable each one is.

Layer 1, enforce uniqueness where it actually lives. A unique constraint at the database level. If the data model says a key is unique, the database should be the thing that guarantees it, not the hope that no two processes collide. This converts a silent, intermittent data corruption into a loud, immediate, catchable error.

Layer 2, make the query defensive. Where a SELECT INTO genuinely could encounter more than one row in a valid state, the query needs to say which one it wants, ordering plus a single-row fetch, rather than assuming the result set has exactly one member. Don't ask the database for the row when a row is possible.

Layer 3, fix the write path. The real cure: the two code paths needed coordination so they couldn't both create the same logical record in overlapping transactions. Constraints and defensive reads keep you safe; fixing the write path is what makes the problem actually go away.

The constraint and the defensive read are guardrails. The write-path fix is the cure. You want all three, because guardrails catch the next bug you haven't met yet.

What I took away from it

The error code points at the crime scene, not the criminal. -811 fired in the SELECT, but the SELECT was the victim. The actual bug was an unenforced uniqueness assumption upstream. Read past the line number.

Unique by convention is a bug with a delay on it. Any invariant your code depends on but the database doesn't enforce is a race condition waiting for enough traffic. If it matters, constrain it.

Intermittent means timing, and timing means concurrency. When a bug refuses to reproduce, stop trying to find the broken line and start looking for two things touching the same state at the same time. The intermittency is the clue, not the obstacle.

A heisenbug you can reproduce on demand is already half fixed. Most of the work in a concurrency bug is making it deterministic. Once you can summon it, the fix is usually small.

The satisfying part wasn't the fix. It was that after it shipped, the 3 AM pages for that job stopped completely. The most boring outcome possible, nothing happening, is exactly what you're working toward in production support.

If you've debugged DB2 under concurrent load, you've probably met -811's cousins: -911 (deadlock/timeout rollback), -803 (duplicate key on a constraint that was enforced), -904 (resource unavailable). They all share the same lesson: the database is telling you the truth about your assumptions, usually at the worst possible hour.

What's the most stubborn intermittent bug you've shipped a fix for? I'd like to hear how you cornered it.

I Wasted 3 Days on AI Integration Until I Found Spring AI — Here's My Full Spring Boot Chatbot Build

Prashant Sasalatti — Fri, 19 Jun 2026 07:55:44 +0000

Six months ago, I was the guy manually stitching together RestTemplate calls to OpenAI's API, writing my own retry logic, parsing raw JSON responses, and wondering why nobody had made this less painful.

Then Spring AI 2.0 dropped and I felt genuinely stupid for not waiting.

This is the exact chatbot I built — from a blank Spring Boot project to a deployed, production-ready AI assistant. No fluff, no "exercise left to the reader." Real code, real mistakes, real gotchas.

What is Spring AI and Why Does It Matter in 2026?

Spring AI is Spring's official abstraction layer for working with AI models. Think of it the way Spring Data abstracted away JDBC boilerplate — Spring AI does the same for LLM integrations.

Version 2.0 (released early 2026) brought:

Unified ChatClient API across OpenAI, Anthropic, Ollama, Azure OpenAI, and more
Built-in streaming support
First-class RAG (Retrieval-Augmented Generation) support with vector store integrations
Advisors API for intercepting and augmenting prompts

For Java developers, this is huge. You no longer need to learn a Python framework or maintain fragile HTTP wrapper classes. This is proper, idiomatic Spring.

Project Setup

I used Spring Boot 3.4.x with Java 21. Here's the core pom.xml section you need:

<properties>
  <java.version>21</java.version>
  <spring-ai.version>2.0.0</spring-ai.version>
</properties>

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.ai</groupId>
      <artifactId>spring-ai-bom</artifactId>
      <version>${spring-ai.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <!-- Spring Boot Web -->
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>

  <!-- Spring AI - OpenAI -->
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
  </dependency>

  <!-- Optional: for streaming responses -->
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
  </dependency>
</dependencies>

Add your API key to application.properties:

spring.ai.openai.api-key=${OPENAI_API_KEY}
spring.ai.openai.chat.options.model=gpt-4o
spring.ai.openai.chat.options.temperature=0.7
spring.ai.openai.chat.options.max-tokens=1024

Never hardcode the API key. I know that sounds obvious but I've seen it in 3 different GitHub repos this year.

Architecture Overview

Before jumping to code, here's the shape of what we're building:

┌─────────────────────────────────────────────────┐
│                  CLIENT (Browser/App)           │
└───────────────────┬─────────────────────────────┘
                    │ HTTP POST /api/chat
                    ▼
┌─────────────────────────────────────────────────┐
│              ChatController (REST Layer)        │
│         Validates input, calls service          │
└───────────────────┬─────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────────┐
│             ChatService (Business Logic)        │
│   Builds prompt, injects system context,        │
│   handles errors, logs usage                    │
└───────────────────┬─────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────────┐
│            Spring AI ChatClient                 │
│   Abstracts the LLM provider (OpenAI here)      │
└───────────────────┬─────────────────────────────┘
                    │
                    ▼
              OpenAI API (gpt-4o)

Simple. Clean. Swappable — if tomorrow you want to run Ollama locally, you change one dependency and one properties line.

Building the Chatbot — Step by Step

The Service Layer

This is where the real logic lives. I kept the controller thin and put everything meaningful here:

@Service
@Slf4j
public class ChatService {

    private final ChatClient chatClient;

    private static final String SYSTEM_PROMPT = """
        You are a helpful assistant for a Java developer support portal.
        Be concise, technical, and accurate.
        If you don't know something, say so — don't hallucinate.
        Always format code snippets using markdown.
        """;

    public ChatService(ChatClient.Builder builder) {
        this.chatClient = builder
            .defaultSystem(SYSTEM_PROMPT)
            .build();
    }

    public String chat(String userMessage) {
        log.info("Sending message to AI. Length: {} chars", userMessage.length());

        try {
            String response = chatClient.prompt()
                .user(userMessage)
                .call()
                .content();

            log.info("Response received. Length: {} chars", response.length());
            return response;

        } catch (Exception ex) {
            log.error("AI call failed: {}", ex.getMessage(), ex);
            throw new ChatServiceException("Unable to process your request. Please try again.", ex);
        }
    }
}

The ChatClient.Builder is auto-configured by Spring AI — you just inject it. The defaultSystem() call sets a persistent system prompt for every conversation. This is your personality config for the bot.

The Controller

@RestController
@RequestMapping("/api/chat")
@Validated
public class ChatController {

    private final ChatService chatService;

    public ChatController(ChatService chatService) {
        this.chatService = chatService;
    }

    @PostMapping
    public ResponseEntity<ChatResponse> chat(@RequestBody @Valid ChatRequest request) {
        String reply = chatService.chat(request.message());
        return ResponseEntity.ok(new ChatResponse(reply));
    }

    public record ChatRequest(
        @NotBlank(message = "Message cannot be blank")
        @Size(max = 2000, message = "Message too long")
        String message
    ) {}

    public record ChatResponse(String reply) {}
}

Records for DTOs. Validation annotations on input. No boilerplate. This is what Java 21 + Spring Boot 3 feels like when it's working well.

Adding Conversation Memory

The above is stateless — every call is a fresh context. For a real chatbot, you need memory. Spring AI handles this with the MessageChatMemoryAdvisor:

@Service
@Slf4j
public class StatefulChatService {

    private final ChatClient chatClient;
    private final InMemoryChatMemory chatMemory;

    public StatefulChatService(ChatClient.Builder builder) {
        this.chatMemory = new InMemoryChatMemory();
        this.chatClient = builder
            .defaultSystem("You are a helpful Java developer assistant.")
            .defaultAdvisors(new MessageChatMemoryAdvisor(chatMemory))
            .build();
    }

    public String chat(String conversationId, String userMessage) {
        return chatClient.prompt()
            .user(userMessage)
            .advisors(advisor -> advisor.param(
                AbstractChatMemoryAdvisor.CHAT_MEMORY_CONVERSATION_ID_KEY,
                conversationId
            ))
            .call()
            .content();
    }
}

Pass a conversationId (like a session ID or user ID) and Spring AI automatically maintains the message history for that conversation. For production, swap InMemoryChatMemory with a Redis or database-backed implementation.

Production Considerations

This is the part most tutorials skip. Here's what bit me in staging:

Rate Limiting

OpenAI has TPM (tokens per minute) limits. Under load, you will hit them. Add a simple token bucket or use Resilience4j:

@Bean
public RateLimiter aiRateLimiter(RateLimiterRegistry registry) {
    return registry.rateLimiter("openai", RateLimiterConfig.custom()
        .limitForPeriod(50)
        .limitRefreshPeriod(Duration.ofMinutes(1))
        .timeoutDuration(Duration.ofSeconds(5))
        .build());
}

Wrap your chatService.chat() call with RateLimiter.decorateSupplier(...).

Timeouts

OpenAI's API can be slow — especially under load. Set explicit timeouts:

spring.ai.openai.chat.options.timeout=30s

And handle TimeoutException separately from other errors so you can return a user-friendly "the AI is taking too long, try again" message instead of a generic 500.

Logging Token Usage

You'll want to track costs. Use Spring AI's response metadata:

ChatResponse response = chatClient.prompt()
    .user(userMessage)
    .call()
    .chatResponse();

Usage usage = response.getMetadata().getUsage();
log.info("Tokens used — prompt: {}, completion: {}, total: {}",
    usage.getPromptTokens(),
    usage.getGenerationTokens(),
    usage.getTotalTokens());

Ship these metrics to your observability stack. Untracked AI costs will surprise you at billing time.

💡 Pro Tip: Use Spring AI's Advisor pattern to implement cross-cutting concerns like content filtering, PII detection, and audit logging — without polluting your service layer. Think of Advisors like AOP for your AI calls.

Deployment Tips

I deployed this on a basic OpenShift container (which is our standard at work). A few things worth noting:

Environment variables over properties files. Set OPENAI_API_KEY as a secret, reference it with ${OPENAI_API_KEY} in properties. Never bake the key into your image.

Health checks matter. Add a custom health indicator that pings the AI provider on startup:

@Component
public class AiHealthIndicator implements HealthIndicator {
    private final ChatClient chatClient;

    @Override
    public Health health() {
        try {
            chatClient.prompt().user("ping").call().content();
            return Health.up().withDetail("provider", "OpenAI").build();
        } catch (Exception e) {
            return Health.down().withDetail("error", e.getMessage()).build();
        }
    }
}

Horizontal scaling is fine — since AI state lives in the LLM provider, your app is stateless (unless you're using in-memory chat history, in which case: pin sessions or use Redis).

Mistakes I Made (So You Don't Have To)

1. Forgetting to set max-tokens.
Without a limit, the model will generate until it's done. Long responses = high cost = slow responses. Always set max-tokens.

2. Putting too much in the system prompt.
I crammed business logic into a 500-word system prompt. It made outputs inconsistent. Keep system prompts focused and short — under 200 words ideally.

3. Not handling empty/null responses.
Spring AI's .content() can return null if the model returns a stop reason other than "stop" (like content filtering). Add a null check.

4. Skipping integration tests.
Unit tests with mocked ChatClient are fine, but you need at least a few integration tests that hit the real API. Model behavior changes between versions. I found a regression this way before it hit production.

5. Using blocking calls in a WebFlux context.
If you're mixing Spring AI's blocking call() API with reactive code, you'll get thread starvation. Either go fully reactive (use .stream() and return Flux<String>) or keep it on a dedicated thread pool.

Key Takeaways

Spring AI 2.0 makes LLM integration feel like writing any other Spring service — idiomatic, testable, and provider-agnostic
The ChatClient builder pattern is your main API surface — learn it well
Memory management (MessageChatMemoryAdvisor) is built-in — don't hand-roll it
Production readiness means: rate limiting, timeouts, token tracking, and proper health checks
The Advisors API is underrated — use it for cross-cutting AI concerns

What's Next

I'm currently adding RAG to this project — embedding our internal documentation into a vector store (PGVector on PostgreSQL) and letting the chatbot answer questions grounded in actual docs rather than hallucinating.

After that: streaming responses with SSE so the UI feels instant instead of waiting for the full completion.

If this was useful, follow me here on DEV — I'll be posting the RAG follow-up next week.

Have you integrated AI into a Spring Boot project? What was the hardest part — the setup, the prompting, or convincing your team it was production-safe? Drop it in the comments. 👇

How to Integrate Apache Kafka with Spring Boot: A Production-Ready Guide

Prashant Sasalatti — Thu, 18 Jun 2026 15:21:15 +0000

When a Spring Boot service needs to talk to another service without waiting on a synchronous HTTP call, message queues are the usual answer. Apache Kafka has become the default choice for this in most backend teams, but a lot of tutorials stop at a "hello world" producer and consumer that would never survive a real production load. Things like consumer retries, error handling, serialization of real objects, and graceful shutdown get skipped, and those are exactly the parts that page you at 2 a.m.

In this tutorial, you will build a Spring Boot application that produces and consumes JSON messages over Kafka. You will configure a producer and a consumer, send a typed object instead of a plain string, handle deserialization errors so one bad message does not block your whole consumer group, and verify the whole thing works end to end. By the end, you will have a small but realistic messaging setup you can build on.

Prerequisites

To follow along, you will need:

Java 17 or later installed. You can check your version by running java -version.
A Spring Boot 3.x project. You can generate one at start.spring.io with the Spring for Apache Kafka dependency added.
A running Kafka broker. The quickest way to get one locally is Docker, which the first step covers.
Basic familiarity with Spring Boot, including how @Component and application.yml work.

Step 1 — Running Kafka Locally with Docker

Before writing any code, you need a broker to talk to. Running Kafka by hand involves Zookeeper, broker configuration, and a fair amount of setup, so you will use Docker Compose to bring up a single-broker cluster instead.

Create a file named docker-compose.yml in your project root:

services:
  kafka:
    image: apache/kafka:3.7.0
    container_name: kafka
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@localhost:9093      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

This uses Kafka's KRaft mode, which removes the Zookeeper dependency that older setups required. The KAFKA_ADVERTISED_LISTENERS value tells clients how to reach the broker; setting it to localhost:9092 is what lets your Spring Boot app connect from your machine.

Start the broker:

docker compose up -d

Confirm it is running:

docker compose ps

You should see the kafka container with a state of running.

With a broker available, you can now configure your application to connect to it.

Step 2 — Configuring the Producer and Consumer

Open src/main/resources/application.yml and add the Kafka configuration:

spring:
  kafka:
    bootstrap-servers: localhost:9092
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.springframework.kafka.support.serializer.JsonSerializer
    consumer:
      group-id: orders-service
      auto-offset-reset: earliest
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.springframework.kafka.support.serializer.ErrorHandlingDeserializer
      properties:
        spring.deserializer.value.delegate.class: org.springframework.kafka.support.serializer.JsonDeserializer
        spring.json.trusted.packages: "com.example.kafka.model"

A few of these settings are worth calling out, because they are the difference between a demo and something production-ready:

JsonSerializer and JsonDeserializer let you send and receive Java objects as JSON rather than hand-serializing strings.
auto-offset-reset: earliest means a new consumer group reads from the beginning of the topic rather than skipping existing messages, which is what you usually want during development.
ErrorHandlingDeserializer wraps the JSON deserializer. This is the important one. Without it, a single malformed message can throw a deserialization exception that the consumer cannot get past, and it will retry that same poisoned message forever, blocking every message behind it.
spring.json.trusted.packages restricts which packages the deserializer will instantiate, which prevents a class of deserialization security issues. Set it to the package where your message classes live.

Step 3 — Defining the Message Model

Create a simple record to represent the message payload. In a package called com.example.kafka.model, create OrderEvent.java:

package com.example.kafka.model;

public record OrderEvent(String orderId, String customer, double amount) {
}

Using a record keeps the model immutable and removes boilerplate. Because the package matches the spring.json.trusted.packages value from Step 2, the consumer will be allowed to deserialize incoming messages into this type.

Step 4 — Writing the Producer

Now create the producer that sends OrderEvent messages to a topic. In com.example.kafka, create OrderProducer.java:

package com.example.kafka;

import com.example.kafka.model.OrderEvent;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.stereotype.Service;

@Service
public class OrderProducer {

    private static final String TOPIC = "orders";

    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public OrderProducer(KafkaTemplate<String, OrderEvent> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void send(OrderEvent event) {
        kafkaTemplate.send(TOPIC, event.orderId(), event)
            .whenComplete((result, ex) -> {
                if (ex == null) {
                    System.out.println("Sent order " + event.orderId()
                        + " to partition "
                        + result.getRecordMetadata().partition());
                } else {
                    System.err.println("Failed to send order "
                        + event.orderId() + ": " + ex.getMessage());
                }
            });
    }
}

KafkaTemplate is the Spring abstraction for producing messages, and Spring Boot autoconfigures it from the properties you set in Step 2. Two details matter here:

Passing event.orderId() as the message key means all events for the same order land on the same partition, which preserves ordering for that order.
send() returns a CompletableFuture. Attaching a whenComplete callback lets you log delivery success or failure instead of firing the message and hoping it arrived. In production you would replace these println calls with a proper logger and metrics.

Step 5 — Writing the Consumer with Error Handling

Create the consumer that listens to the orders topic. In com.example.kafka, create OrderConsumer.java:

package com.example.kafka;

import com.example.kafka.model.OrderEvent;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.stereotype.Component;

@Component
public class OrderConsumer {

    @KafkaListener(topics = "orders", groupId = "orders-service")
    public void consume(OrderEvent event) {
        System.out.println("Received order " + event.orderId()
            + " from " + event.customer()
            + " for $" + event.amount());
        // business logic goes here
    }
}

The @KafkaListener annotation does the heavy lifting: Spring polls the topic, deserializes each message into an OrderEvent, and calls this method for every record.

The error handling you set up in Step 2 is what makes this safe. Because the consumer uses ErrorHandlingDeserializer, a message that cannot be parsed into an OrderEvent is handed off as a failed record instead of crashing the listener. By default, Spring's error handler will retry a few times and then log and skip the bad record, so one corrupt message does not stall the entire partition.

Step 6 — Verifying It Works End to End

Wire the producer to a startup runner so you can see a message flow through. In your main application class, add a bean that sends a test event once the context is ready:

package com.example.kafka;

import com.example.kafka.model.OrderEvent;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;

@SpringBootApplication
public class KafkaApplication {

    public static void main(String[] args) {
        SpringApplication.run(KafkaApplication.class, args);
    }

    @Bean    CommandLineRunner runner(OrderProducer producer) {
        return args -> producer.send(
            new OrderEvent("ORD-1001", "Acme Corp", 249.99));
    }
}

Run the application:

./mvnw spring-boot:run

In the logs, you should see the producer confirm delivery and the consumer report receipt:

Sent order ORD-1001 to partition 0
Received order ORD-1001 from Acme Corp for $249.99

Seeing both lines means the message was serialized to JSON, published to the broker, pulled by the consumer group, deserialized back into an OrderEvent, and processed. The full round trip is working.

Conclusion

In this tutorial, you set up a local Kafka broker with Docker, configured a Spring Boot producer and consumer for typed JSON messages, and added deserialization error handling so a single bad message cannot block your consumer group. You also keyed messages by order ID to preserve per-order ordering and logged delivery results instead of sending blindly.

From here, you can extend this setup in several directions. You can route repeatedly failing messages to a dead letter topic so they can be inspected later, add a RetryTopic configuration for delayed retries, or introduce a schema registry with Avro if you need stronger contracts between producers and consumers.