Learn
Four articles on idempotency itself - what it means, how a key is designed, what the options are in Spring, and how it fits with at-least-once messaging.
These four are about the problem, not the library. They assume you have been handed a duplicate side effect and now have to decide what to do about it, and they are honest about the options that are not this library: a processed-events table, a unique constraint, a distributed lock, a platform.
Read them in order if the whole subject is new. Otherwise take the question that is yours.
- 01What does idempotency mean, and why is it hard?What idempotency actually meansWhy "the same request twice has the same effect once" is harder than it sounds, where duplicates actually come from, and why HTTP's definition of an idempotent method is not the property you need.
- 02How do I design an idempotency key, and what do I store against it?How idempotency keys workWho generates the key, what it must be scoped to, what happens on reuse with a different body, how long to keep records, and what to store as the result.
- 03What are my options for handling duplicate work in a Spring application?Idempotency in Spring BootThe options a Spring engineer actually has - a processed-events table, a unique constraint, @Cacheable, a distributed lock, Spring Integration, a library - and what each one costs.
- 04How does idempotency fit with the outbox pattern and at-least-once messaging?Idempotency in message-driven systemsThe outbox pattern, at-least-once delivery, and why a duplicate message is evidence that the first attempt may have died halfway, not only noise to filter out.