Custom deduplication header vs. inherent idempotency for Cloud Run retry safety

Goal: ensure that a Cloud Run service processing at-least-once messages does not perform duplicate writes when the invoking service retries delivery.

Constraint: Cloud Run itself does not retry; the caller (e.g., Pub/Sub push or Cloud Tasks) may redeliver the same request with a potentially different value for the platform‑provided X‑Cloud‑Run‑Request‑ID header. Therefore any deduplication mechanism must either rely on a stable identifier supplied by the caller or make the handler logic inherently idempotent.

Uncertainty: choosing between passing a custom deduplication token (e.g., UUID) that the service checks against a durable store, versus designing the operation to be idempotent by using PUT‑style updates or unique database constraints, given trade‑offs in latency, storage cost, and implementation complexity.

Which approach provides a more reliable and maintainable way to prevent duplicate writes under these conditions?