4 ms·
Strongly agree that idempotency should be understood as part of the application, and not as part of the transport. I find it insightful to think about a transp
by felixhuttmann 5y ago
Strongly agree that idempotency should be understood as part of the application, and not as part of the transport.
I find it insightful to think about a transport layer that is much less reliable than the internet: traditional/snail mail. In a proper business communication, every invoice has an invoice number such that the recipient can know whether they processed that invoice previously or not.
- eweise 5y agoAn invoice number is not the same as an idempotency-key. The idempotency-key is create by the recipient, sent to server and an invoice number is returned. Invoice number is clearly part of the application layer since its domain specific but idempotency-key is a generalized concept that prevents duplicate actions from occurring when there is no other key.
- mikem170 5y agoLike a PO (purchase order) number?
- nivertech 5y agoThese are 2 different kinds of idempotency: 1. request (also command/mutation) idempotency (using Idempotency-Key in HTTP, or clientMutationId in GraphQL/Relay) 2. entity idempotency (using invoice_id) (1) is more generic one and can be applied to any mutation with a side-effect, for example sending an email. It can also work with server-side generated IDs. It can be implemented as a generic middleware via cache or DB with TTL. That's what Stripe is doing. (2) is more application-specific, for mutations actually changing a state (usually a DB row/document, or an entity managed by another service). Here the entity id should have a uniqueness constraint in the DB, and you should use either a semantic key (i.e. customer name), or a client-side generated ID like for example UUID. I use a combination of both, to reduce a load on the DB while still having the same guarantees as using DB only.