DEV Community: Nazrin Suleymanli

Does finally Run Before return? What javac Actually Does

Nazrin Suleymanli — Wed, 23 Sep 2026 14:49:47 +0000

Here's a small Java snippet. Before reading on, decide what it returns:

static int a() {
    int x = 1;
    try {
        return x;
    } finally {
        x = 99;
    }
}

If you said 99, you're in good company. I used to think the same thing: "finally runs before return, so x becomes 99 first, then gets returned."

The actual answer is 1.

finally does run before the method exits. But that's not the same as running before return. Let's see why.

`return` is two steps, not one

When the JVM executes return x; inside a try that has a finally, it does this:

Evaluate the expression (x) and store the result in a hidden local variable
Run the finally block
Return the stored value

So conceptually, the compiler turns our method into this:

static int a() {
    int x = 1;
    int tmp;
    tmp = x;      // 1. value captured: tmp = 1
    x = 99;       // 2. finally runs: only x changes
    return tmp;   // 3. returns 1
}

By the time finally touches x, the return value has already been copied somewhere else. It's no different from:

int x = 1;
int tmp = x;
x = 99;
// tmp is still 1

Don't trust me, trust the bytecode

Compile the class and run javap -c. The relevant part looks like this (slightly trimmed):

 0: iconst_1
 1: istore_0      // x = 1
 2: iload_0
 3: istore_1      // tmp = x   <-- the hidden variable (slot 1)
 4: bipush 99
 6: istore_0      // x = 99    <-- finally
 7: iload_1
 8: ireturn       // return tmp
 9: astore_2      // exception path starts here
10: bipush 99
12: istore_0      // x = 99    <-- finally, again
13: aload_2
14: athrow
Exception table:
   from  to  target  type
     2    4     9    any

Two things stand out:

istore_1 copies the value of x into a separate slot. finally writes to slot 0 (x), and ireturn reads from slot 1. They never meet.
The finally code (bipush 99; istore_0) appears twice. There's no "finally instruction" in the JVM. javac simply copies the finally block in front of every exit point: once for the normal return, once for the exception path (the any handler in the exception table).

With catch, it's the same rule

static int demo(boolean fail) {
    int x = 1;
    try {
        if (fail) throw new RuntimeException();
        return x;
    } catch (RuntimeException e) {
        x = 2;
        return x;
    } finally {
        x = 99;
    }
}

Roughly desugared:

static int demo(boolean fail) {
    int x = 1;
    int tmp;
    try {
        if (fail) throw new RuntimeException();
        tmp = x;
        x = 99;          // finally copy #1
        return tmp;      // 1
    } catch (RuntimeException e) {
        x = 2;
        tmp = x;
        x = 99;          // finally copy #2
        return tmp;      // 2
    } catch (Throwable t) {
        x = 99;          // finally copy #3
        throw t;
    }
}

demo(false) returns 1, demo(true) returns 2. finally runs on every path and changes the result on none of them.

Objects behave differently (sort of)

The hidden variable stores whatever return evaluates to. For objects, that's a reference, not a copy of the object:

static StringBuilder b() {
    StringBuilder sb = new StringBuilder("hi");
    try {
        return sb;
    } finally {
        sb.append("!");
    }
}
// returns "hi!"

tmp and sb point to the same object, so mutating it in finally is visible to the caller.

But reassigning the variable is not:

finally {
    sb = new StringBuilder("new");
}
// still returns "hi" (tmp points to the old object)

This is exactly the same rule as the int case. Only the variable changes, not what was already captured.

The one that actually bites: `return` inside `finally`

static String c() {
    try {
        throw new IllegalStateException("important!");
    } finally {
        return "finally";
    }
}

This returns "finally", and the exception disappears. No stack trace, no log, nothing. A return in finally overrides both the try's return value and any exception in flight.

In production code, this means silently swallowed errors. Most static analysis tools flag it (Sonar rule java:S1143), and you should treat it as a bug.

Where this matters in real code

1. Cleanup that must always happen

lock.lock();
try {
    updateBalance();   // might throw
} finally {
    lock.unlock();
}

If updateBalance() throws and unlock() is not in finally, the lock is never released, and every other thread waiting on it blocks forever. finally fixes this because javac copies it onto every exit path, as we saw in the bytecode.

2. try-with-resources: Java 7's fix for resource leaks

Before Java 7, closing a resource correctly meant writing the finally yourself:

Connection c = ds.getConnection();
try {
    return query(c);
} finally {
    c.close();
}

It was easy to forget, and with several resources, it quickly turned into nested try/finally blocks. Forgotten close() calls meant leaked connections and file handles.

Java 7 introduced try-with-resources (and the AutoCloseable interface), so the compiler writes this for you:

try (Connection c = ds.getConnection()) {
    return query(c);
}

Under the hood, it's the same finally we've been looking at, with the same order of operations:

String tmp = query(c);   // 1. result captured while the connection is still open
c.close();               // 2. connection closed
return tmp;              // 3. result returned

That's why returning a query result from inside try-with-resources is safe.

As a bonus, if both query(c) and close() throw, try-with-resources keeps the original exception and attaches the close() failure to it as a suppressed exception. A hand-written finally would let the close() exception replace the original one.

3. Beyond a single method: Spring's `@PreDestroy`

finally only covers the lifetime of one method call. Some resources persist for the lifetime of the application, such as a Kafka producer or a connection pool. Those need to be cleaned up when the application shuts down, not when a method returns.

Spring handles this with @PreDestroy. When the application context closes, Spring destroys its beans and calls their @PreDestroy methods:

import jakarta.annotation.PreDestroy;

@Component
public class EventPublisher {

    private final KafkaProducer<String, String> producer = ...;

    @PreDestroy
    public void cleanup() {
        producer.flush();   // send anything still buffered
        producer.close();
    }
}

Same idea as finally, "always clean up", just at a different scope: per method vs. per application.

Note that neither of these runs if the JVM is killed outright (for example, System.exit() skips finally, and kill -9 skips everything). "Finally always runs" holds as long as the method actually exits.

The 30-second interview answer

If you get this question in an interview, here's a compact answer:

"The return value is evaluated and stored before finally runs, so reassigning a primitive in finally doesn't affect it. Mutating an object does, because only the reference was captured. Under the hood, javac inlines the finally block before every exit point. And a return inside finally overrides everything, including exceptions, which is why it's considered a bug."

Summary

In `finally` you...	Effect on the returned value
reassign a primitive (`x = 99`)	none, value already captured
mutate an object (`sb.append("!")`)	visible, same object
reassign a reference (`sb = new ...`)	none, old reference captured
`return` something	overrides everything, swallows exceptions

return captures its value before finally, and the method exits after finally.

For the formal version, see JLS §14.20.2: Execution of try-finally and try-catch-finally.

Local Transactions Aren't Enough: The Dual-Write Problem in Microservices

Nazrin Suleymanli — Mon, 21 Sep 2026 18:59:08 +0000

Our system shared a lot of state with an external BPMN process engine. The engine decided which flow a user should go through, and to make that decision it needed the user and the user type to exist on both sides: in our database and in the engine.

That "on both sides" turned out to be harder than it sounds. We'd create a user in our own database, then push it to the engine, and the two would quietly drift apart. Sometimes the engine already had the user and rejected our save with an "already exists" error. Sometimes our write succeeded and the push didn't, so the engine never heard about a user we thought we'd shared. Two systems, no shared transaction, and no reliable answer to a simple question: does the other side actually know about this user?

The dual-write problem

What we hit has a name: the dual-write problem. It shows up any time a single operation has to write to two systems that don't share a transaction. In our case that was our PostgreSQL database and the process engine, but it's the same story with a database and Kafka, a database and a search index, or any two systems you update together.

Here's why it's unavoidable. A database transaction can only protect writes inside that database. When your method does two things:

@Transactional
public void createUser(User user) {
    userRepository.save(user);        // writes to our database
    engineClient.registerUser(user);  // writes to the engine
}

the @Transactional annotation only covers the first line. The engine call is a network request to a completely separate system, and it has no idea our database transaction exists. So the two writes can't succeed or fail together. One of them can land while the other doesn't.

And once you accept that, you realise there's no ordering that saves you. Whichever line you put first, there's a moment between the two where a crash, a timeout, or a network blip leaves the two systems disagreeing. The gap is small, but in production small gaps get hit thousands of times.

The fixes that don't work

Before reaching for a pattern, we tried the obvious things. Each one looks reasonable and each one leaves a hole.

Database first, then the engine. Save the user locally, then push to the engine. If the engine call fails, we've got a user in our database the engine never heard about. The two are already out of sync, and now we need cleanup logic to find and retry those orphaned users.

Engine first, then the database. Flip the order. Now if our local save fails after the engine already accepted the user, the engine knows about a user our own system has no record of. Same problem, opposite direction.

Wrap both and roll back manually. "Fine, if the second write fails, I'll undo the first." This is where people write a try/catch that deletes the user when the engine call throws. But the compensating delete can fail too, or the service can crash between the failed engine call and the cleanup. You're now writing error-handling for your error-handling, and there's still a gap.

The pattern underneath all three is the same: as long as the two writes are independent, there is always a moment where one has happened and the other hasn't. You can shrink that window, but you can't close it. What we actually need is a way to make "save the user" and "remember to tell the engine" part of the same transaction, so they can never come apart.

The fix: the transactional outbox

The idea is small once it clicks. Instead of calling the engine inside your method, you write a row into an outbox table in your own database, in the same transaction as the user. Two writes, one database, one transaction. They commit together or not at all.

CREATE TABLE outbox (
    id           BIGSERIAL PRIMARY KEY,
    event_type   VARCHAR(100) NOT NULL,   -- e.g. "USER_REGISTERED"
    payload      JSONB        NOT NULL,   -- the user data to send
    status       VARCHAR(20)  NOT NULL DEFAULT 'PENDING',
    created_at   TIMESTAMP    NOT NULL DEFAULT now()
);

Now the method changes. There's no engine call here anymore, just two local writes that live or die together:

@Transactional
public void createUser(User user) {
    userRepository.save(user);
    outboxRepository.save(
        new OutboxEntry("USER_REGISTERED", toJson(user))
    );
}

That's the whole trick. If this transaction commits, both the user and the intent to notify the engine are safely stored. If anything throws, both roll back, and there's no half-done state to clean up. The engine hasn't been called yet, but we've made a durable promise to call it, and that promise is sitting in the same database as the data it's about.

The network call still has to happen, of course. It just doesn't happen here. We've turned an unreliable "write to two systems at once" into a reliable "write to one system," and moved the risky part somewhere we can retry it safely.

Getting it to the engine: the relay

The outbox table is now a to-do list of things that need to reach the engine. Something has to read that list and actually make the calls. That something is the relay.

The simplest version is polling. A scheduled job wakes up every few seconds, grabs the pending rows, sends each one to the engine, and marks it done:

@Scheduled(fixedDelay = 5000)
public void publishOutbox() {
    for (OutboxEntry entry : outboxRepository.findByStatus("PENDING")) {
        engineClient.register(entry.getPayload());
        entry.setStatus("SENT");
        outboxRepository.save(entry);
    }
}

This is what I built first, and it worked. It isn't the fanciest option, but it's easy to reason about and easy to debug, which counts for a lot in production. A more advanced setup would drive the relay from the database changelog instead of polling (change data capture, with a tool like Debezium), and that's the direction I'd take it next. But polling every few seconds was more than enough to keep the two sides in sync, and I'd rather ship the simple version that works than the clever one that might.

There's one catch, and it's exactly where our original problem came from. The relay is at-least-once: if the service restarts after the engine call but before the row is marked SENT, that row gets sent again. So the engine gets the same user twice and throws the "already exists" error.

In a perfect world you'd fix this on the engine side, make it treat a repeat registration as a no-op. But I couldn't touch the engine; it's an external system I don't control. So I handled it on my side instead: the relay treats "already exists" as a success. If the engine says the user is already there, that's fine, that's the state I wanted anyway. I mark the row SENT and move on.

It's not the textbook answer, but it's the realistic one when you own only one side of the integration.

When you actually need this

The outbox pattern isn't free. You're adding a table, a relay, and a bit of operational surface to keep an eye on. So it's worth being honest about when it earns that cost.

You need it when two systems must agree and you can't lose the update between them: a user that has to exist on both sides, an order that must reach billing, a record that has to land in another service no matter what. Anywhere a lost write leaves two systems quietly disagreeing, the outbox is the pattern that closes the gap.

You can skip it when the second write doesn't have to be reliable. If it's fine to miss the occasional update, or you can recompute the other side later, a direct call with some retries is simpler and good enough. Not every integration deserves an outbox, and reaching for it everywhere just moves the complexity around.

For us it was the right call because the whole system depended on both sides knowing about the same users. Once the outbox was in place, the "already exists" errors and the silent drift just stopped. The two sides stayed in sync, and I stopped getting paged about users that existed in one place but not the other.

Stop Chasing Exactly-Once. Your Kafka Consumer Just Needs to Not Care

Nazrin Suleymanli — Sun, 20 Sep 2026 14:47:11 +0000

Every few months a team I talk to decides they need exactly-once delivery in Kafka. They read the docs, discover processing.guarantee=exactly_once_v2, wire up transactional producers, and pat themselves on the back for building something bulletproof.

Most of them never needed it.

Exactly-once is one of the most over-reached-for features in event-driven systems. It sounds like the obvious, responsible choice (who wants duplicates?) but in practice it buys a lot of complexity and performance cost to solve a problem that a much simpler pattern usually solves better. In three years of building Kafka consumers in production, I've reached for it exactly zero times. Here's why.

Why exactly-once is so tempting

The pull toward exactly-once is completely understandable. "Duplicates" sounds like a bug, and exactly-once sounds like the grown-up, production-ready answer. When you're staring at a double-charged customer, a config flag that promises the problem simply won't happen is the most attractive thing in the world.

There's also the framing in the docs. Kafka lists its guarantees as at-most-once, at-least-once, and exactly-once, and read top to bottom, it looks like a difficulty ladder where exactly-once is the top rung, the "best" one. Nobody wants to build the lesser system, so teams reach for the rung labelled strongest.

Guarantee	Duplicates?	Data loss?	Cost
at-most-once	No	Possible	Cheap
at-least-once	Possible	No	Cheap
exactly-once	No	No	Expensive, and Kafka-only

But that ladder is misleading. These aren't "worse" and "better" versions of the same thing, they're different trade-offs, and the cheap middle option is the one most systems actually want.

And to be fair, the instinct isn't wrong. Duplicates are a real problem. Left unhandled, they double-charge customers, send emails twice, and corrupt counters. The disagreement isn't about whether duplicates matter. It's about where you solve them. Exactly-once tries to solve them at the transport layer, before your code ever sees them, and that's where the hidden costs start.

The hidden cost

Exactly-once isn't free, and the price shows up in three places.

First, performance. Exactly-once in Kafka is built on transactions, and transactions add coordination overhead on every message. You pay for it in throughput and latency. For a lot of systems that's an acceptable trade, but you're paying it whether or not you actually had a duplicate problem worth solving.

Second, complexity. Turning on exactly_once_v2 isn't a single switch either. Under the hood it's really several moving parts working together: an idempotent producer so retries don't create duplicates, transactional writes, and a transactional consumer to tie the read and write into one unit. You inherit all of that coupling and complexity, and every extra moving part is a part that can break at 2 a.m.

Third, and this is the one that changes the whole argument: Kafka's exactly-once only works Kafka to Kafka. It covers the read, process, and write cycle when everything stays inside Kafka. The moment your consumer does something to the outside world, calling a payment gateway, writing to a separate database, sending an email, that action is outside the transaction. Exactly-once will not protect it.

So if you're charging a customer, you still have to make that charge idempotent yourself. Which means you did all the work of setting up exactly-once, and you still wrote the dedup logic you were trying to avoid. You paid twice and solved the problem once.

What to do instead

Start from the other end. Assume duplicates will happen, because with at-least-once they will, and make your consumer not care.

In practice that means one thing: make your side effects idempotent. Give every event a stable ID, keep track of the ones you've already handled, and skip anything you've seen before. The charge runs once no matter how many times the event arrives. That's it. No transactions, no coupling, no throughput tax. Just a consumer that shrugs at a redelivery and moves on.

@KafkaListener(topics = "orders", groupId = "billing-service")
@Transactional
public void handle(OrderCreatedEvent event) {
    if (processed.existsById(event.getId())) return; // seen it, skip
    charge(event);
    processed.save(new ProcessedEvent(event.getId()));
}

Five lines. No pipeline-wide mode, no transactional producer, nothing to reason about at 2 a.m. The event can arrive ten times and the customer is charged once.

The nice part is that this scales down as well as up. A tiny service and a twelve-service saga need the exact same discipline: every step has to be safe to retry. Idempotency is a property you build into each handler, so it composes naturally as your system grows, while exactly-once is a mode you switch on for a whole pipeline and hope nobody steps outside of.

So my rule of thumb is simple. Reach for idempotency first. It solves the duplicate problem where the duplicates actually cause damage, in your code, right next to the thing that touches the outside world.

If you want the concrete implementation, with the dedup table and the Spring Boot consumer, I wrote up the full how-to here:

Nazrin Suleymanli

Sep 19

Your Kafka Consumer Will See Every Event Twice - Here's How to Handle It

#java #kafka #microservices #springboot

6 min read

When exactly-once actually earns its place

None of this means exactly-once is useless. It's a real feature that solves a real problem, and there's a case where it genuinely fits: pure Kafka to Kafka pipelines with no outside world involved. If you're reading from a topic, transforming, and writing back to another topic, and correctness of the result matters, like a running aggregation or a stateful stream processor, exactly-once is doing exactly what it was designed for. There's no external side effect to make idempotent, so the transactional model covers the whole job.

The point isn't that the feature is bad. It's that it's a specialized tool, not the default. The moment a real side effect enters the picture, and in most business systems it does almost immediately, idempotency is the pattern carrying the weight, with or without exactly-once on top.

So before you turn it on, ask one question: does my consumer actually touch anything outside Kafka? If the answer is yes, and it usually is, start with idempotency. Make your consumer not care how many times an event arrives, and the duplicate problem quietly disappears where it was actually going to hurt you.

Your Kafka Consumer Will See Every Event Twice - Here's How to Handle It

Nazrin Suleymanli — Sat, 19 Sep 2026 15:52:30 +0000

It's 2 a.m., and your on-call phone buzzes. A customer was charged twice for the same order. You dig into the logs - the OrderCreated event was processed, then processed again seconds later. Nothing crashed. No exception was thrown. Kafka did exactly what it promised: it delivered the message at least once. The bug isn't in Kafka. It's an assumption that your consumer would ever see each event only once.

In this tutorial, we'll fix that assumption: why duplicates are normal, why the obvious consumer code fails silently, and how to make a Spring Boot Kafka consumer idempotent - safe to run any number of times with the same result as running it once.

Why does this happen?

Kafka gives you an at-least-once delivery guarantee. Not exactly once - at least once. That word "least" is doing a lot of work, and it's the root of our problem.

Here's the normal flow of a consumer:

Kafka hands your consumer a message.
Your code processes it (charges the customer, writes to the DB).
Your consumer commits the offset - essentially a bookmark saying "I've handled everything up to here."

The trouble lies in the gap between steps 2 and 3. If your service crashes, is redeployed, or the consumer group rebalances after the work is done but before the offset is committed, Kafka has no idea step 2 ever happened. So when the consumer restarts, it reads from the last committed offset and delivers that same OrderCreated event again.

Think of the offset as a bookmark in a book. You read a page (process the event), then move the bookmark forward (commit the offset). Now imagine your phone dies after you read the page but before you move the bookmark. When you reopen the book, you start from the old bookmark and read that page again.

Nothing is broken. Kafka is doing exactly what it promised. The double charge comes from our code assuming each event arrives once.

Rebalancing makes this worse in production. Every deploy, every scale-up, every pod restart in Kubernetes triggers a rebalance, so the more you scale, the more often you hit this window.

The naive approach (and why it fails)

Most consumers start out looking like this:

@KafkaListener(topics = "orders", groupId = "billing-service")
public void handleOrderCreated(OrderCreatedEvent event) {
    paymentService.charge(event.getCustomerId(), event.getAmount());
    log.info("Charged customer {} for order {}", event.getCustomerId(), event.getOrderId());
}

This is clean, readable, and works perfectly in every demo. Ship it, and it will happily process thousands of orders without complaint.

Then one day, a pod restarts mid-processing, Kafka redelivers the last event, and paymentService.charge(...) runs a second time. There's no error, no stack trace, just a customer with two charges and a support ticket.

The reason this is so easy to miss is that the code is correct in isolation. The bug isn't in any single line. It's in the assumption baked into the whole method: that it will run only once per order. Kafka never promised that.

So the fix isn't "handle the exception" or "add a try/catch." There's nothing to catch. The fix is to make the operation idempotent, so it is safe to run any number of times with the same result as running it once.

A quick way to picture idempotency: pressing an elevator call button once and pressing it five times gives the same result. The elevator still comes once. A light switch is not idempotent: every press changes the state. Our charge() method is currently a light switch. We're going to turn it into an elevator button.

The fix: an idempotency key + a dedup store

The idea is to give every event a stable identity and remember which ones we've already handled. Kafka can redeliver all it wants. We just refuse to act on the same ID twice.

One thing to get right before any code: the event ID must be a stable ID that travels in the payload (an eventId or orderId that the producer sets), not a UUID.randomUUID() you generate at the time of consumption. If you mint a fresh ID on each consume, every redelivery looks "new" and the whole scheme is pointless.

First, a table whose only job is to remember processed events. The event_id is the primary key, so the database itself guarantees we can never store the same one twice:

CREATE TABLE processed_events (
    event_id     VARCHAR(255) PRIMARY KEY,
    processed_at TIMESTAMP NOT NULL DEFAULT now()
);

@Entity
@Table(name = "processed_events")
public class ProcessedEvent {
    @Id
    private String eventId;
    private Instant processedAt = Instant.now();
    // constructors, getters
}

Now the consumer. Two things must happen together, or not at all: recording the event as processed, and doing the actual work. So we wrap them in a single @Transactional method:

@KafkaListener(topics = "orders", groupId = "billing-service")
@Transactional
public void handleOrderCreated(OrderCreatedEvent event) {
    if (processedEvents.existsById(event.getEventId())) {
        log.info("Duplicate event {} — skipping", event.getEventId());
        return;
    }

    paymentService.charge(event.getCustomerId(), event.getAmount());
    processedEvents.save(new ProcessedEvent(event.getEventId()));
}

Why the single transaction matters: the charge and the "I've processed this" marker now commit as one unit. If charge() throws halfway through, the transaction rolls back the marker as well, so Kafka will redeliver and we'll retry cleanly. And if a rare concurrent duplicate slips past the existsById check, the primary key on event_id rejects the second insert, the transaction fails, and no second charge is committed.

So there are really two layers here: the existsById check is for speed (skip the obvious duplicates cheaply), and the primary key is for correctness (the database is the last line of defense when two duplicates race). They work together.

What about Redis?

Redis is a popular, faster alternative - a single atomic SET billing:event:<eventId> 1 NX EX 86400 does the "write only if absent" check (NX) and auto-expires the key after a day (EX). But Redis can't join your database transaction: if you mark the event seen in Redis and then the DB write fails, you're left with a "processed" marker and no work done, and the redelivery gets skipped too. So use Redis when the side effect isn't critical (send a notification once, dedupe analytics), and keep the event ID in the same database as your work when correctness really matters, like billing.

Edge cases worth knowing

Offset commit strategy

A nice consequence of the dedup store: you no longer need heroics around offset committing. Even if the offset commit fails after your transaction commits, the redelivered event just hits the dedup check and gets skipped.

That said, don't leave Spring Kafka on naive auto-commit (enable.auto.commit=true), which commits offsets on a timer regardless of whether your work has finished. If the consumer dies after a commit but before the work completes, the event is lost. Instead, commit after the listener succeeds. The simplest way is AckMode.RECORD: Spring commits each record's offset automatically when the listener method returns without throwing an exception, with no extra code on your part.

factory.getContainerProperties().setAckMode(AckMode.RECORD);

If you want finer control, switch to manual acks (AckMode.MANUAL_IMMEDIATE) and acknowledge explicitly at the point you decide the work is done:

@KafkaListener(topics = "orders", groupId = "billing-service")
public void handle(OrderCreatedEvent event, Acknowledgment ack) {
    // dedup check + charge ...
    ack.acknowledge(); // only now: "this offset may be committed"
}

Either way, the principle is the same: commit the offset after the work, never before. The dedup store is your safety net against redelivery, not an excuse to commit early.

The dedup table grows forever

Duplicates only ever arrive within a short window (a rebalance, a restart), so you don't need to keep event IDs around for months. Add a small scheduled job that deletes rows older than a few days:

DELETE FROM processed_events WHERE processed_at < now() - INTERVAL '7 days';

Duplicates on the producing side

This tutorial fixes the consumer. If your service also publishes events while writing to its own database, you have a related-but-separate problem: the DB write can succeed while the Kafka publish fails, or vice versa. The standard fix there is the transactional outbox pattern: write the event to an outbox table in the same transaction as your data, and relay it to Kafka separately. Worth a follow-up read once the consumer side is solid.

When you need this and when you don't

Reach for a dedup store whenever the side effect isn't naturally idempotent: charging money, sending an email, incrementing a counter, or calling an external API that performs an action. These are the operations that hurt when they run twice.

You may not need one when the operation is inherently idempotent. If your consumer just sets the absolute state UPDATE orders SET status = 'PAID' WHERE id = ? running it twice changes nothing the second time. In those cases, making the write itself idempotent (an upsert keyed by ID, setting absolute rather than relative values) can be enough on its own.

The mental shift is the whole point: stop trying to make Kafka deliver exactly once; it won't. Instead, make your consumer not care how many times it's called. Once each event carries a stable ID and your side effects are idempotent, that 2 a.m. double charge simply can't happen. The redelivery still arrives. Your code just shrugs and moves on.

DEV Community: Nazrin Suleymanli

Does finally Run Before return? What javac Actually Does

return is two steps, not one

Don't trust me, trust the bytecode

With catch, it's the same rule

Objects behave differently (sort of)

The one that actually bites: return inside finally

Where this matters in real code

1. Cleanup that must always happen

2. try-with-resources: Java 7's fix for resource leaks

3. Beyond a single method: Spring's @PreDestroy

The 30-second interview answer

Summary

Local Transactions Aren't Enough: The Dual-Write Problem in Microservices

The dual-write problem

The fixes that don't work

The fix: the transactional outbox

Getting it to the engine: the relay

When you actually need this

Stop Chasing Exactly-Once. Your Kafka Consumer Just Needs to Not Care

Why exactly-once is so tempting

The hidden cost

What to do instead

Your Kafka Consumer Will See Every Event Twice - Here's How to Handle It

When exactly-once actually earns its place

Your Kafka Consumer Will See Every Event Twice - Here's How to Handle It

Why does this happen?

The naive approach (and why it fails)

The fix: an idempotency key + a dedup store

What about Redis?

Edge cases worth knowing

Offset commit strategy

The dedup table grows forever

Duplicates on the producing side

When you need this and when you don't

`return` is two steps, not one

The one that actually bites: `return` inside `finally`

3. Beyond a single method: Spring's `@PreDestroy`