Idempotency
Studies in this cluster, in series order. Each one keeps its own URL.
APIs
HTTP semantics, retries, idempotency, GraphQL tradeoffs, and contract design.
Idempotency
6 studies- 1.API Idempotency KeysStripe-style Idempotency-Key for safe retries — fingerprint, unique (account,key), in_progress/completed, response cache, ~24h TTL.
- 2.At-Least-Once vs Exactly-Once DeliveryAt-most-once loses; at-least-once duplicates; exactly-once needs transactional producer+consumer+sink; effectively-once is idempotent consumers + dedup.
- 3.Request Fingerprinting for Idempotent APIsCanonical JSON (sorted keys, stable numbers) hashed with method+path; include/exclude map; Stripe-style 422 on mismatch; schema-evolution with null defaults.
- 4.Retry Storms, Backoff & JitterNaive retries amplify outages. Combine exponential backoff, full jitter, Retry-After, circuit breakers, client budgets, and idempotency keys.
- 5.Idempotent HTTP Methods & Safe RetriesRFC 9110 — safe vs idempotent. GET/HEAD/OPTIONS/TRACE safe; PUT/DELETE idempotent but not safe; POST not idempotent; PATCH depends. Idempotency-Key still needed for POST and for concurrent PUT races.
- 6.Transactional Outbox & Inbox PatternsDual-write is the bug. Write domain row + outbox row in one DB transaction; poller/CDC publishes; inbox dedupes at-least-once deliveries into effectively-once processing.