Posts for: #Idempotency

Notification Deduplication

2026-04-12sohilladhani

#distributed-systems #mobile #push-notifications #idempotency

Your retry logic fires. The user gets the same notification twice. They think your app is broken. They’re not wrong. The Problem with Retries Push delivery is at-least-once by design. Your server sends to APNs/FCM, the network hiccups, you don’t get a response, so you retry. APNs might have delivered the first one. The user now sees two identical alerts. The fix lives at two levels: your server and the gateway.

Making Consumers Idempotent

2026-02-05sohilladhani

#distributed-systems #kafka #messaging #idempotency #system-design #java

Exactly-once delivery is impossible across boundaries. Here’s the pattern that actually works: at-least-once delivery with idempotent consumers.

Exactly-Once Delivery is a Lie

2026-02-04sohilladhani

#distributed-systems #kafka #messaging #idempotency #system-design

Kafka says exactly-once. Your consumer processed the message twice anyway. Here’s why exactly-once is impossible across system boundaries.

Idempotency: Why Retries Need It

2026-01-08sohilladhani

#distributed-systems #idempotency #reliability #java #system-design

How to make operations safe to retry. Idempotency keys, database patterns, and why retrying non-idempotent operations causes data corruption.