Marking the Inbox row PROCESSED before the business commit suppresses the retry

Call `process(event)` in the post's sample and one database transaction opens at the method boundary ^[8]. The Inbox lookup, the call into `businessService.apply` and `inbox.markProcessed()` all run inside it, so the database can commit or roll back those changes together ^[12]. The acknowledgment back to the broker happens outside that scope ^[10].

Three of the five steps the post lists are database work; the remaining two, delivery and the ack, belong to the broker ^[13]. A database transaction normally cannot make a Kafka acknowledgment atomic with the database commit, which leaves the consumer straddling two systems ^[10]. The annotation is a scope declaration, and the broker never sees it.

The two wrong orderings cost you different things. Commit the business operation in one transaction and let the Inbox update fail in another, and the broker may redeliver an event that looks unprocessed, so the consumer executes the business operation again ^[6]. That failure is survivable if the business write tolerates replay. Mark the Inbox row processed first and then roll the business transaction back, and the Inbox says PROCESSED while the business data says the opposite; the retry is suppressed because the Inbox reports the event as already handled, and the post says the system has effectively lost the opportunity to recover ^[7]. Keep both writes in one transaction and a failure on the Inbox update rolls the whole thing back, leaving the event available for retry ^[5].

The sample reads before it decides: `findByEventId`, an early return on `isProcessed`, then apply, then mark ^[8]. It contains no insert, so a row for that event id has to exist before `process` runs ^[15].

Writing as czetsuya on dev.to, the author said "It is tempting to think of this as one atomic operation" ^[16], and that "The important part isn't the @Transactional annotation itself. The important part is understanding which operations actually participate in that transaction." ^[9]

For the annotation to cover what the diagram claims, `businessService.apply` has to write through the same datasource and join the caller's transaction. The post's own warning is that the Inbox update and the business operation can accidentally end up in different transactional boundaries even inside one database ^[3]. The post does not disclose a broker acknowledgment mode, stopping at the two-systems statement ^[10].

The evidence is one developer's account of a reliability problem found while building an event system called NERV Event ^[11], not a measured failure population. The state machine it describes is small enough to check by hand: RECEIVED, PROCESSING, PROCESSED, against `event_id` ^[4].