Un planificador de recordatorios que puede ejecutarse dos veces sin enviar el mismo email

A las doce del 8 de agosto, Klivka comprueba que ha llegado el momento de enviarte el recordatorio semanal para Ana. Deja anotado que hay un email pendiente y, una hora después, vuelve a revisar los recordatorios.

Esa segunda revisión es intencionada. Si alguien crea un recordatorio a las 12:30, Klivka puede encontrarlo sin esperar hasta el día siguiente. El de Ana también aparece en las dos revisiones porque su fecha sigue siendo el 8 de agosto. Si Klivka no recordase que ya lo encontró al mediodía, podría programar el mismo email por segunda vez.

Para saber que ya ha preparado ese email, Klivka guarda un registro en la base de datos antes de enviarlo. La base de datos conserva dos cosas distintas: el recordatorio semanal para contactar con Ana y el registro del email concreto que toca enviar el 8 de agosto. La semana siguiente se mantiene el mismo recordatorio, pero se crea otro registro para el nuevo email.

Cada dato tiene una función: el recordatorio conserva el calendario y el registro del email conserva el resultado. Además, los emails y las notificaciones de la aplicación pueden gestionarse por separado porque cada canal tiene su propio registro.

Cómo reconoce la base de datos un duplicado

La base de datos necesita saber que ambos intentos se refieren al mismo email. Klivka lo consigue con un índice único, una regla de la base de datos que solo permite un registro para cada combinación de recordatorio, fecha prevista y canal. En este ejemplo, la combinación es el recordatorio semanal de Ana, el 8 de agosto y el email.

Las dos revisiones intentan crear el mismo registro. El índice único acepta la primera y omite la segunda.

Al mediodía, Klivka pide a la base de datos que guarde el email sobre Ana previsto para el 8 de agosto. La base de datos crea ese registro. A la una, Klivka vuelve a pedirle que guarde el mismo email, con el mismo recordatorio, la misma fecha y el mismo canal, y la base de datos no crea un segundo registro. Aunque las dos revisiones hicieran la petición casi al mismo tiempo, el índice único solo permitiría guardar uno.

Klivka también se guarda hasta qué día ha buscado recordatorios, y solo actualiza esa fecha cuando termina la revisión. Si el proceso se interrumpe a mitad, la fecha no cambia y la siguiente revisión vuelve a comprobar esos días. Puede encontrar emails que ya había registrado antes del fallo, pero el índice único evita que los registre otra vez.

Guardar el trabajo antes de enviar el email

Klivka podría enviar el email directamente mientras busca recordatorios, pero entonces cualquier fallo afectaría a los dos pasos. El proveedor de emails podría aceptar el email de Ana justo antes de que Klivka perdiera la respuesta. En ese caso, una revisión posterior encontraría de nuevo el recordatorio sin saber si el email anterior llegó a enviarse. Marcarlo como enviado antes de llamar al proveedor tendría el problema contrario, ya que un fallo podría dejar como enviado un email que nunca salió.

Por eso, Klivka separa los dos pasos. La revisión guarda un registro de envío pendiente, y otro proceso lo recoge, envía el email y anota el resultado. Si el proveedor de emails informa de un fallo, ese proceso puede volver al mismo registro, que conserva el número de intentos y el estado actual. Dicho de otro modo, Klivka guarda el trabajo antes de pedir al proveedor que envíe el email.

Antes de enviar el email, el proceso vuelve a comprobar la regla. Puede que ya hayas contactado con Ana, pospuesto el recordatorio o desactivado los avisos por email desde la última revisión. En cualquiera de esos casos, Klivka cancela el envío pendiente y deja intacto el historial de envíos ya completados.

Es verdad que la tabla adicional tiene un coste. Cada fecha programada genera un registro por canal, y los registros pendientes deben mantenerse al día cuando cambian las reglas. Un producto con recordatorios puntuales y un solo canal podría guardar en el propio recordatorio una marca que indique si ya se envió.

Klivka admite recordatorios recurrentes, dos canales, reintentos y un historial de envíos, así que cada envío necesita su propio registro. El proveedor de email sigue fuera de la transacción de la base de datos, por lo que Klivka no puede asegurar que vaya a salir un único email. Su garantía es más acotada: Klivka guarda como máximo un registro de envío por cada regla, fecha prevista y canal.