[jnbridge]

This is one of those problems that gets significantly harder when your system spans multiple runtimes or platforms.

A few patterns that have worked well in practice:

1. Idempotency keys at the API boundary — every side-effecting call gets a client-generated UUID, and the receiver deduplicates. Simple, but think carefully about the TTL of your dedup window.

2. Outbox pattern — instead of directly calling the external service, write the intent to a local "outbox" table in the same transaction as your state change. A separate process polls the outbox and delivers. Debezium + CDC makes this quite clean.

3. For cross-system workflows: treat the saga orchestrator as the single source of truth for step completion. Each step checks its completion status before executing, so steps must be idempotent OR the orchestrator tracks state.

In practice, designing for at-least-once delivery + idempotent receivers is more reliable than trying to achieve exactly-once through distributed coordination. Exactly-once across system boundaries is effectively a myth outside of systems that support two-phase commit (and even then it's fragile).

[dakiol]

I think this suggestions are fine but none of them solve the problem here. The "client" (the service the OP owns) can be as atomic and transactional as one wants, but if the "server" (the 3rd party service being called by the "client") doesn't offer either a) idempotency or b) a retrieval mechanism for existing resources, then the "client" can't do anything about the original stated problem.