// notas

La clave de idempotencia va en el origen, no en el destino

Generar el identificador de deduplicación en el sistema que recibe la petición no sirve de nada si el reintento llega por otro camino.

1 min de lectura
IntegraciónArquitectura

Error que cometí y me costó una tarde de depuración: generar la clave de idempotencia en el servicio que recibe la petición.

Si el consumidor reintenta, manda la misma petición otra vez, y mi servicio genera una clave nueva a partir del timestamp de llegada. Resultado: dos claves distintas para la misma operación lógica, y dos documentos creados.

La clave tiene que venir del origen y ser estable en el tiempo:

// Mal: cambia en cada reintento
const key = `${cardCode}-${Date.now()}`;
 
// Bien: la misma operación produce siempre la misma clave
const key = `pedido-web-${pedidoId}`;

Y el destino la guarda junto al registro creado para poder responder al reintento con el resultado original en vez de crear uno nuevo.

Regla que me quedó: si el reintento no puede regenerar exactamente la misma clave, no es una clave de idempotencia.

Si esto te resultó útil o tienes un caso parecido en tu empresa, escríbeme: me gusta conversar sobre estos problemas aunque no termine en un proyecto.