Idempotency Keys
GET/PUT/DELETE, NATURALLY, IDEMPOTENT hain, LEKIN, POST (jaise, "CREATE PAYMENT") NAHI hai — AGAR, NETWORK FAILURE ki WAJAH SE, CLIENT ko, RESPONSE NA MILE, aur, WOH, RETRY kare, EK DUSRA, DUPLICATE PAYMENT, ACCIDENTALLY, CREATE HO SAKTA hai.
Idempotency Key PATTERN — CLIENT, HAR "SENSITIVE", POST REQUEST ke SAATH, EK UNIQUE KEY (jaise, EK UUID) BHEJTA hai, EK HEADER mein (jaise Idempotency-Key). SERVER, IS KEY ko, EK CACHE/DATABASE mein, STORE karta hai — AGAR, SAME KEY, DOBARA, AAYE, SERVER, NAYA OPERATION, PERFORM NAHI karta, BALKI, PEHLA, STORED, RESULT, RETURN kar deта hai.
@PostMapping("/payments")
public ResponseEntity<PaymentDto> createPayment(
@RequestHeader("Idempotency-Key") String idempotencyKey,
@RequestBody PaymentRequestDto request) {
Optional<Payment> existing = paymentRepository.findByIdempotencyKey(idempotencyKey);
if (existing.isPresent()) {
return ResponseEntity.ok(toDto(existing.get())); // DUPLICATE — PEHLA result, RETURN
}
Payment payment = paymentService.process(request, idempotencyKey);
return ResponseEntity.status(HttpStatus.CREATED).body(toDto(payment));
}
// Client, HAR PAYMENT attempt (INCLUDING RETRIES) mein, SAME key bhejta hai:
// Idempotency-Key: 7c9e6679-7425-40de-944b-e07fc1f90ae7- GET/PUT/DELETE = naturally idempotent, POST = NAHI
- Idempotency-Key header = client, HAR retry mein, SAME key bhejta hai
- Server, SAME key dobara AANE par, NAYA operation NAHI karta — pehla result, return karta hai
STORED, IDEMPOTENCY, KEYS, FOREVER, NAHI, RAKHE, JAATE — TYPICALLY, 24 GHANTE SE, EK, HAFTE tak, ki, EXPIRATION, SET ki, JAATI hai — PURANE, KEYS, AUTOMATICALLY, CLEANUP ho jaate hain, DATABASE, GROWTH, CONTROL mein, RAKHNE ke liye.
Database, UNIQUE, CONSTRAINT (jaise, idempotency_key COLUMN PAR, UNIQUE INDEX), EK, EXTRA, SAFETY, NET hai — CHAHE, APPLICATION-LEVEL, LOGIC, MEIN, KOI, RACE, CONDITION, HO, DATABASE, DUPLICATE, INSERT ko, REJECT kar DEGA.
ALTER TABLE payments ADD CONSTRAINT uq_idempotency_key UNIQUE (idempotency_key);