Live data from Hacker News

The First Idempotency Key

hatchet.run

11–12 of 12 posts

Re: The First Idempotency Key

#11

Some might call this pedantic, but I think physical reality provided us the earliest idempotency keys, which were natural keys in specific systems. Some effects are idempotent because they address physical reality in a way that converges or provides mutual exclusion. The pigeon-hole principle isn't an instruction guide for birds, it just describes the reality of occupancy. An egg-tooth keeps pecking, escaping at most…

Natural idempotence requires deep understanding of the domain, which developers (and coding agents) do not always have. Also, it's still a limited solution, which doesn't solve the generic case. So it's each much easier to use technical idempotency solutions like: - stamp every initial request / domain event with the UUID (idempotency key) - use client-side IDs instead of using server-generated ones with RETURNING -…

I didn't really mean to emphasize CRUD when I mentioned REST. Just that it is an example of a natural mapping for some domains. I'm not a fan of anything trying to solve distribute system problems with only middleware. The end-to-end mapping needs to traverse the messaging layer, but cannot really be made robust when the endpoint are naive to the distributed reality.

A similar analogy is how 2-phase commit protocols enact (virtual) escrow.

Re: The First Idempotency Key

#12

Earlier quoted context omitted.

Natural idempotence requires deep understanding of the domain, which developers (and coding agents) do not always have. Also, it's still a limited solution, which doesn't solve the generic case. So it's each much easier to use technical idempotency solutions like: - stamp every initial request / domain event with the UUID (idempotency key) - use client-side IDs instead of using server-generated ones with RETURNING -…

I didn't really mean to emphasize CRUD when I mentioned REST. Just that it is an example of a natural mapping for some domains. I'm not a fan of anything trying to solve distribute system problems with only middleware. The end-to-end mapping needs to traverse the messaging layer, but cannot really be made robust when the endpoint are naive to the distributed reality. A similar analogy is how 2-phase commit protocols…

It doesn't matter CRUD, REST, 2PC, or middleware in general. From my PoV they're all technical solutions used to avoid deep modeling of the domain and its workflows, and instead trying to model the real world using generic primitives without understanding it first, or maybe with surface-level understanding only

The dichotomy is generic vs custom/bespoke:

- generic (CRUD / REST / RDBMS+SQL+ACID Tx / Tx Scripts / 2PC / BPMN / Admin UIs) - also SmartUIs/Fat Clients (VB, Delphi, SPAs, etc.)

vs

- custom (DDD / CQRS/ES / Sagas / Process Managers / Durable Executions / TBUI)

Also, learning data engineering and BI helps one better model the real world than generic methods. It's somewhat similar to CQRS/ES, but with much more prior art

Post reply on HN