Mastering Idempotency

In a distributed system, you will receive the same message twice. It's not a matter of 'if', but 'when'. Idempotency ensures that processing the same event multiple times has no additional effect.

1. Why do duplicates happen?

Usually because of network timeouts. Service A sends a message to Service B. Service B processes it but the "Ack" (Acknowledgment) gets lost. Service A thinks it failed and sends it again. Without idempotency, you might charge the user's card twice!

2. Implementation Strategies

• **Inbox Pattern:** Save the ID of every processed message in a table. Before processing a new message, check if the ID already exists.
• **Upsert Logic:** Use SQL `UPSERT` or `MERGE` commands so that if the record exists, the second call just updates it (or does nothing) instead of creating a duplicate.

4. Interview Mastery

Q: "How do you handle idempotency at the API level?"

Architect Answer: "We require an **Idempotency-Key** header in the request. We store the result of that key's processing in Redis for 24 hours. If we receive the same key again, we skip the business logic and just return the cached response. This protects our system from double-clicks and retry-logic from the client side."