Exactly-once delivery is a lie your broker tells your handler
Every exactly-once mode is at-least-once plus dedup inside one system. The moment your handler calls an external API, the guarantee ends at your function boundary.
Tag archive
Every exactly-once mode is at-least-once plus dedup inside one system. The moment your handler calls an external API, the guarantee ends at your function boundary.

Introduction Networks fail. Timeouts happen. Clients retry. Message brokers may redeliver...

Introduction In a microservices architecture, a single business operation often needs to...
The failure that taught me to stop trusting the network Yesterday a user updated an order...
_How to guarantee no transaction event is ever silently lost, even when Kafka goes down _ Every...

A follow-up. The architecture is sound. The first six weeks of running it were not. Here are four bugs the round-trip taught me — two about the abstraction, two about the substrate underneath.
How do you guarantee that an event is sent to the message broker only if the database transaction succeeds? Learn about the Transactional Outbox pattern.

Most people know the Transactional Outbox Pattern at a high level. What’s often missing are the...

In enterprise applications dealing with payroll, compensation, and benefits data, every change...
Just publish the event after saving to the database. How hard can it be? Famous last words....

Part 1 of this series introduced the outbox pattern as a reliable approach for message delivery in...

This is a two-part series; for part 2, see here. The outbox pattern is a well-known design pattern...