Notificaciones de pedidos por WhatsApp sin mensajes duplicados
Publicado el 2026-11-14 por frfrand
Arquitectura de eventos e idempotencia para avisos de compra, envío e incidencias por WhatsApp.
# Notificaciones de pedidos por WhatsApp sin mensajes duplicados
Una tienda cambia el estado de un pedido y dispara un evento. Si el webhook se repite, el worker se reinicia o el proveedor responde después de un timeout, el sistema puede emitir dos avisos idénticos. Un evento 'procesado' no equivale siempre a una entrega efectiva. Hay que distinguir los estados de negocio, los intentos de envío y la aceptación del proveedor.
Qué notificar
Selecciona eventos que realmente aporten valor: pedido confirmado, pago acreditado, preparado, entregado al transportista, excepción de envío, entrega completada y devolución. Evita enviar notificaciones por cada actualización interna o microestado. El texto debe incluir referencia reconocible, estado confirmado y una acción útil; no datos de pago ni secretos.
Modelo de outbox
Cuando una operación cambia el estado en la base de datos, crea en la misma transacción un registro de notificación pendiente con una clave única, por ejemplo pedido_id + tipo_evento + version_estado + canal. Un worker procesa esa outbox en segundo plano. De esta forma el evento no se pierde si la aplicación cae después de guardar el pedido, antes de enviar el mensaje.
Máquina de estados
Usa pendiente, enviando, aceptado, entregado, fallido definitivo y requiere revisión. Para un timeout incierto, consulta el estado del proveedor o reconcilia antes de reenviar; el reintento ciego puede duplicar mensajes si el primer intento sí salió. Mantén un identificador de correlación y, si está disponible, el ID del mensaje remoto.
Plantillas y preferencias
Fuera de la ventana de atención, utiliza plantillas adecuadas a la categoría y reglas vigentes. Comprueba consentimiento y preferencias del cliente, separando notificaciones transaccionales de marketing. Una petición de baja comercial no debe reactivarse automáticamente por un pedido posterior sin fundamento.
Observabilidad y métricas
Mide tasa de eventos duplicados bloqueados, cola pendiente, latencia hasta aceptación, errores por plantilla, entregas y bajas. Establece alertas por acumulación y una bandeja de revisión para errores permanentes, como número no válido. Limita el volumen por destinatario y evita inundaciones si se importan pedidos históricos.
Prueba de fallos
Ejecuta el mismo webhook 10 veces, desconecta al proveedor, corta un worker entre estados y envía eventos fuera de orden. El resultado esperado es una sola intención de aviso por cambio de negocio, con trazabilidad. Amplía la implementación con webhooks seguros y tareas en segundo plano.
Preguntas frecuentes
¿Es necesario construir todo a medida? No siempre. Empieza con el proceso mínimo y añade integraciones cuando exista una necesidad demostrable.
¿Cómo se evitan errores repetidos? Con identificadores estables, validaciones, registros y pruebas de reintentos.
¿Cuándo intervenir manualmente? Ante datos ambiguos, errores persistentes y acciones de alto impacto.
Conclusión
Documenta el proceso y prueba sus fallos antes de ampliar volumen. En ArduMaker puedes explorar la infraestructura y las integraciones aplicables a este escenario.