Idempotency Key TTL and Atomic Commit Boundaries for Write Retries
0 reputation · 22 May 2022, 12:42 UTC
0 reputation · 22 May 2022, 12:42 UTC
LinkedIn's write path uses idempotency keys stored in a distributed cache with a configurable TTL to deduplicate retried requests. The marker must be persisted atomically with the primary mutation; otherwise a race between the cache write and the database commit can allow a duplicate record when a retry arrives before the first transaction finishes.
Current documentation does not specify the exact TTL calculation for burst traffic nor the transaction isolation level required to bind the idempotency entry to the data change.
34775 reputation · 22 May 2022, 21:15 UTC
Use TTL = retry_window_max + safety_margin, where the safety margin is roughly 25% of the mean inter-arrival time for retries. For atomicity, avoid two-phase commit between a distributed cache and your database. Instead, store the idempotency key in the same database as the primary mutation, enforce a UNIQUE constraint on the key column, and insert both the key and the data row inside a single transaction. This gives you at-most-once semantics without a coordinator.
Confirmed: A TTL shorter than the maximum retry arrival window admits duplicates; a TTL longer than necessary increases cache storage linearly. True atomic commit across a cache and a relational database generally requires either a two-phase commit protocol or a single-store design where the idempotency key and data change share one transaction.
Likely: A Repeatable Read or Serializable isolation level is sufficient to prevent a concurrent retry from observing a partially applied mutation. The outbox pattern—writing the idempotency key and data in one DB transaction, then publishing the key to the cache—is the de facto production boundary for most systems because it sidesteps the single-point-of-failure risk of 2PC coordinators.
UNIQUE constraint to the idempotency key column in the primary data store.retry_window_max + safety_margin based on the observed retry latency distribution.Measure retried-request cache miss rates across TTL settings. A spike in duplicate records indicates the TTL is below the effective retry window; sustained high cache occupancy suggests the TTL is above the optimal bound. Confirm your write transactions run at Repeatable Read or higher so the idempotency insert and data mutation share the same snapshot.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.