100c1c⁝ Idempotency alternative

How to get the same safety guarantees with less coordination

Idempotency is a “check-then-act” safety net. It requires keeping state (keys) and coordination (locks/transactions) to prevent data corruption. The other architectural approach is to design systems where duplicates naturally do not matter, removing the need to track keys entirely.

some examples

Level	Strategy	Description	Cost
Level 0	At-Least-Once (No De-dup)	Do nothing at app level. Duplicates cause double effects.	Risk of data corruption.
Level 1	Idempotency Keys	Track message or business IDs and ignore duplicates.	Extra storage and key management.
Level 2	State Machine	UPDATE ... WHERE status = prev to enforce transitions.	Low storage cost, strict workflows needed.
Level 3	Commutative Updates	CRDTs or merge funcs that converge regardless of order.	High design complexity, little coordination.
Level 4	Immutable Event Log	Append-only events, fix by writing new events not overwrites.	Storage growth, needs compaction/snapshots. Need a versioning strategy, or replays and reads will hurt. Careful event versioning

Commutative Updates

• product view counts
• “items sold” metric
• accumulated discount used per campaign

State-Machine Guardrails ( Low cost, but requires strict workflows. )

The most robust “logic-based” improvement is to define a strict Finite State Machine (FSM). This doesn’t remove idempotency, but it makes it implicit rather than explicit storage.

Instead of checking a separate idempotency_keys table, the business entity is the idempotency check.

• Scenario: You want to pay an Order.
• Logic: UPDATE Order SET status = 'PAID' WHERE id = 123 AND status = 'PENDING'.

If a duplicate message arrives:

1. The first one matches status = 'PENDING' and updates it to PAID.
2. The second one fails to match the WHERE clause (0 rows updated).

Don’t need a separate lock or key table. The domain state itself rejects the duplicate operation naturally.

100c1⁝ Idempotency Keys