idempotency-design

Design idempotent APIs using idempotency keys, deduplication, and retry-safe implementations.

1|Updated Mar 21, 2026
One-click install
npx skills add https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts --skill idempotency-design-kalilurrahman
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: idempotency-design
Source: https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts/tree/main/01-software-dev/idempotency-design
Command: npx skills add https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts --skill idempotency-design-kalilurrahman

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Non-idempotent operations like payments and order creation cause duplicate charges, double bookings, and data corruption when clients retry after network timeouts or failures. ## Core Features & Use Cases - Idempotency Keys: Client-generated UUIDs with server-side deduplication using Redis caching or database unique constraints. - Distributed Locking: Redis-based locks prevent race conditions when concurrent requests share the same idempotency key. - Retry Logic: Exponential backoff strategies with safe retry policies for POST, PUT, and DELETE requests. - Use Case: A payment API receives a POST request that times out; the client retries with the same Idempotency-Key header and receives the cached original response instead of charging the customer twice. ## Quick Start Design an idempotent payment endpoint with idempotency keys, Redis deduplication, and retry logic for my Flask API.

Frequently Asked Questions about idempotency-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make a POST API endpoint idempotent?

Require clients to send a unique Idempotency-Key header (typically a UUID) with each request. The server stores processed keys in Redis or a database and returns the cached response when a duplicate key arrives instead of re-executing the operation.

Redis vs database unique constraint for idempotency deduplication?

Redis offers fast lookups with automatic TTL expiration, ideal for high-throughput APIs. Database unique constraints provide stronger durability guarantees. Using both together gives defense in depth for critical operations like payments.

How long should idempotency keys be cached?

Cache responses for at least 24 hours to cover typical retry windows after failures. The examples use a 24-hour TTL for API responses and 7 days for email send markers, with daily cleanup jobs for database-stored keys.

How do I prevent race conditions with concurrent idempotent requests?

Use a distributed lock via Redis SET NX with an expiration timeout around the check-and-process logic. Requests that fail to acquire the lock receive a 409 Conflict response indicating the operation is already processing.

Does Stripe support idempotency keys for payments?

Yes, Stripe accepts an idempotency_key parameter on charge creation and handles deduplication server-side. Reusing the same key with different parameters raises an IdempotencyError, while identical retries return the original charge.