Does Crystal require database-level idempotency keys to prevent duplicate writes during retries?

Goal

Determine whether a Crystal application can retry a side-effecting operation without creating duplicate writes using only the standard library and language concurrency features.

Constraints and uncertainty

Crystal 1.x does not include a built-in atomic retry, circuit breaker, or distributed transaction coordinator. The Cells actor model isolates state within a process but does not automatically reconcile state after a failed network retry. Strict types can express idempotent-wrapper interfaces, but they do not guarantee that an executed method is idempotent. Whether database unique constraints or idempotency keys are therefore mandatory remains unresolved, and third-party ORM retry behavior has not been verified against current compiler versions.

Open questions

• Can Crystal standard-library features alone prevent duplicate writes on retry?
• Are database-level unique constraints or idempotency keys required for side-effecting operations?
• Does any maintained Crystal ORM provide transaction-level retry safety out of the box?