El cliente pulsa un botón, la pantalla tarda en responder y vuelve a pulsarlo. Poco después aparecen dos solicitudes. Deshabilitar el botón durante el envío puede mejorar la experiencia, pero no resuelve todos los reintentos posibles: una aplicación, una integración o la propia persona pueden repetir la operación desde otro lugar. El negocio necesita distinguir entre repetir la misma intención y crear una nueva. Esa diferencia debe existir en el servidor y en las reglas de operación, especialmente cuando una solicitud reserva recursos o inicia un cobro.
Separa la intención de cada intento de envío
Imagina una solicitud como un sobre identificado. La red puede transportar ese sobre varias veces, pero su contenido sigue representando una misma operación. El sistema necesita reconocer esa identidad para no ejecutarla de nuevo. A esta propiedad se le suele llamar idempotencia. No exige que el dueño del negocio defina el mecanismo técnico, pero sí que acuerde qué constituye una nueva solicitud. Corregir una dirección, repetir un envío fallido y comprar otra unidad pueden necesitar tratamientos diferentes aunque involucren el mismo producto.
Pide una respuesta que permita recuperar el resultado
La documentación de Stripe describe claves de idempotencia para reconocer reintentos de determinadas solicitudes. El principio útil para tu proyecto es conservar una relación entre la intención y el resultado obtenido. Cuando se pierde la respuesta, la aplicación debe poder recuperar el estado de esa operación antes de crear otra. También hace falta decidir qué ocurre si se reutiliza una identificación con información diferente. Silenciar esa diferencia puede ocultar errores de integración; conviene devolver una explicación que permita corregirlos de manera controlada.
Diseña el estado incierto sin culpar al usuario
Después de una interrupción, un mensaje como algo salió mal puede empujar a repetir todo. Es preferible comunicar que se está verificando si la solicitud fue recibida y ofrecer una consulta del estado. Si todavía no puede confirmarse, explica qué referencia conservar y qué canal usar. No presentes una operación como rechazada únicamente porque la pantalla no recibió respuesta. En el equipo de atención, utiliza la misma referencia para buscarla; así evitas que una llamada termine creando un segundo registro por falta de información compartida.
Verifica duplicados más allá del botón
La revisión debe incluir dos clics rápidos, una recarga durante el envío y un reintento después de perder conexión. Comprueba cuántos registros, notificaciones y reservas se produjeron, no solamente qué mensaje apareció. Pregunta cuánto tiempo se conserva la protección y qué sucede cuando ese plazo termina. Si una operación desencadena otras, cada etapa puede necesitar su propia prevención de duplicados. Documenta el procedimiento para corregir una duplicación real sin borrar la evidencia que permita entender su causa y evitar que vuelva a ocurrir.
DE LA LECTURA A LA ACCIÓN
Para aplicar hoy
- Identifica una intención de negocio de forma independiente a sus reintentos.
- Recupera el estado antes de crear otra operación tras una interrupción.
- Verifica registros y efectos secundarios, además del comportamiento del botón.
Fuentes y referencias
Documentación para profundizar. Los ejemplos de esta guía son didácticos.