Idempotent @Retry vs Transactional Outbox for duplicate‑write prevention in Quarkus

Goal: guarantee that a Quarkus service annotated with @Retry does not create duplicate database rows when a transient exception forces a retry of the emitting method.

Constraint: the service processes only a few dozen messages per minute, so added latency or operational complexity from an extra outbox table and its processor must be weighed against the risk of incorrectly assuming idempotency.

Uncertainty: teams must decide whether to rely on application‑level idempotency checks (e.g., unique‑key pre‑read) or to adopt the transactional outbox pattern, and it is unclear which option yields lower end‑to‑end latency and storage overhead for low‑throughput workloads.

Which approach introduces less operational overhead for services handling fewer than 100 messages per minute? How does each pattern affect end‑to‑end latency when a retry is triggered? What are the trade‑offs in storage growth and failure recovery between the two patterns?