Recordatorios recurrentes: cómo gestionar la complejidad oculta
"Añade un recordatorio todos los martes." Seis palabras. Fácil de decir. Pero detrás de esta frase se esconde uno de los problemas más subestimados del desarrollo de aplicaciones: las reglas de recurrencia. He pasado días enteros gestionando casos límite que nadie anticipa antes de encontrarlos.
Puntos clave a recordar:
- Los recordatorios recurrentes parecen simples pero esconden una enorme complejidad (gestión de meses desiguales, zonas horarias, excepciones).
- El almacenamiento híbrido (regla en el padre, ocurrencias generadas bajo demanda) es el mejor compromiso rendimiento/flexibilidad.
- La UX progresiva — simple por defecto, potente como opción — es la clave para no perder a ningún usuario.
- Un buen sistema de recurrencia necesita al menos 4 tipos de reglas y una gestión robusta de los casos límite.
¿Por qué los recordatorios recurrentes son tan complejos de implementar?
Cuando piensas en "recordatorio recurrente", probablemente imaginas un simple setInterval o un cron job. La realidad es mucho más retorcida. TAMSIV soporta cuatro tipos de recurrencia: diaria, semanal, mensual y personalizada. El caso diario toma 10 minutos en codificarse. ¿El caso "el último viernes de cada mes"? Días.
El problema fundamental es que el calendario no es regular. Los meses tienen 28, 29, 30 o 31 días. Las semanas se superponen con los meses. Existen los años bisiestos. Y las zonas horarias añaden una capa adicional de caos.
Como desarrollador en solitario de TAMSIV, tuve que tomar decisiones arquitectónicas críticas desde el principio para evitar tener que refactorizar todo más tarde.
¿Cómo gestionar el problema del "31 de cada mes"?
Este es el caso clásico que todo desarrollador de calendario teme. El usuario crea un recordatorio el 31 de enero con recurrencia mensual. ¿Qué pasa en febrero? ¿En abril?
Existen tres enfoques:
- Saltar el mes: no hay recordatorio en febrero. Mala UX — el usuario piensa que es un error.
- Desplazamiento al último día: el recordatorio pasa al 28 (o 29) de febrero, 30 de abril, etc. Es intuitivo.
- Forzar el 1 del mes siguiente: lógico para algunos casos, pero confuso.
Elegí la opción 2 — el desplazamiento automático al último día del mes. ¿Por qué? Porque es lo que el usuario espera sin pensarlo. Cuando alguien dice "todos los meses", quiere decir "más o menos en la misma fecha cada mes". El pragmatismo supera el rigor matemático.
Esta elección tiene un impacto directo en el código. Para cada ocurrencia, primero calculo la fecha teórica, luego verifico si existe en el mes objetivo con Math.min(jourOriginal, dernierJourDuMois). Simple en apariencia, pero hay que hacerlo para cada ocurrencia generada.
¿Cuál es el mejor modelo de almacenamiento para eventos recurrentes?
Esta es la pregunta arquitectónica clave. Dos escuelas se enfrentan:
Opción A: almacenar todas las ocurrencias. Generas 365 filas en la base de datos para un recordatorio diario anual. Ventaja: consultas simples. Inconveniente: explosión de la base de datos y complejidad de modificación (cambiar la hora del recordatorio = modificar 365 filas).
Opción B: almacenar solo la regla. Guardas "cada martes a las 9h" y calculas sobre la marcha. Ventaja: base de datos ligera. Inconveniente: consultas complejas para saber "¿qué recordatorios caen esta semana?".
Opté por un modelo híbrido en TAMSIV: la regla de recurrencia se almacena en el evento padre, y las ocurrencias se generan bajo demanda. Cuando un recordatorio se convierte en un evento de calendario — por ejemplo, a través del sistema de agenda con filtros — se crea una ocurrencia concreta en la base de datos.
Concretamente, la estructura de la base de datos se parece a esto:
- Tabla padre: contiene el título, la descripción y un campo JSON con la regla de recurrencia (
type,interval,daysOfWeek,endDate) - Tabla de ocurrencias: creada bajo demanda cuando el usuario interactúa (completa, pospone, modifica)
- Cálculo dinámico: para la visualización del calendario, las ocurrencias futuras se calculan en el lado del cliente
Este modelo híbrido permite evitar las consultas N+1 mientras se mantiene la base de datos bajo control. Con el sistema de caché optimizado, el rendimiento sigue siendo excelente incluso con cientos de recordatorios.
¿Cómo crear un recordatorio recurrente por voz?
Una de las ventajas únicas de TAMSIV es que puedes crear recordatorios complejos hablando de forma natural. El pipeline vocal de IA analiza tu frase y extrae automáticamente la regla de recurrencia.
Ejemplos concretos:
- "Recuérdame regar las plantas cada 3 días" → recurrencia personalizada, intervalo de 3 días
- "Reunión de equipo cada lunes y miércoles a las 10h" → semanal, días específicos
- "Pagar el alquiler el primero de cada mes" → mensual, día fijo con gestión de casos límite
- "Cumpleaños de María el 15 de marzo cada año" → anual
El LLM (a través de OpenRouter) descompone la frase en intenciones estructuradas. La función create_calendar_event recibe entonces un objeto con los parámetros de recurrencia ya extraídos. El usuario solo tiene que validar — o modificar — antes de guardar en la base de datos.
Esta es la fuerza del dictáfono integrado: hacer invisible la complejidad técnica para el usuario final.
¿Cuáles son las trampas de las zonas horarias con los recordatorios?
Si piensas que los meses irregulares son molestos, espera a ver las zonas horarias. Un recordatorio diario a las 9h se activa a las 9h hora local. Pero, ¿qué es "9h hora local" cuando el usuario viaja? ¿Cuando ocurre el cambio de hora de verano/invierno?
Dos estrategias posibles:
- Almacenar en UTC y convertir al renderizar: limpio pero problemático para "9h todos los días" (que puede convertirse en 8h o 10h según la estación)
- Almacenar en hora local con zona horaria: más fiel a la intención pero más complejo de gestionar en la base de datos
En TAMSIV, opté por el almacenamiento en UTC con la zona horaria de referencia del usuario. Cuando el cálculo de la ocurrencia cae en un día de cambio de hora, el sistema se ajusta para mantener la hora local estable. Este es el comportamiento que esperan los usuarios de Google Calendar o Apple Calendar.
¿Cómo diseñar la UX de los recordatorios sin abrumar al usuario?
El desafío de la UX es tan importante como el desafío técnico. ¿Cómo presentar reglas de recurrencia potencialmente complejas sin perder al usuario ocasional?
La respuesta: el diseño progresivo (progressive disclosure).
Así es como lo implementé en TAMSIV:
- Nivel 1 — 4 botones simples: Todos los días, Todas las semanas, Todos los meses, Sin recurrencia. Cubre el 80% de las necesidades.
- Nivel 2 — Panel avanzado: accesible a través de "Personalizar". Días de la semana seleccionables, intervalo personalizado (cada N días/semanas/meses), fecha de finalización opcional.
- Nivel 3 — Casos complejos: "El último viernes del mes", "El segundo martes de cada mes". Interfaz especializada para estas reglas raras.
El principio rector: simple por defecto, potente como opción. El usuario ocasional nunca debe sentirse perdido. El usuario avanzado nunca debe sentirse limitado. Este principio también guía el sistema de onboarding de la aplicación.
También implementé la navegación por deslizamiento en las pantallas de recordatorios para fluidificar la experiencia.
¿Qué diferencia hay con los recordatorios de Google Calendar o Todoist?
Las soluciones existentes como Todoist o Google Calendar gestionan bien las recurrencias. Pero todas tienen el mismo defecto: la entrada manual.
Con TAMSIV, la creación vocal cambia fundamentalmente la ecuación. Decir "recuérdame enviar el informe todos los viernes a las 17h" es incomparablemente más rápido que navegar por 3 menús para configurar lo mismo manualmente.
Además, el sistema de gamificación recompensa la finalización de los recordatorios recurrentes, lo que crea un círculo virtuoso de productividad. Cada tarea recurrente completada alimenta tu racha y te acerca al siguiente nivel.
¿Qué lecciones aprender de la implementación de las recurrencias?
Después de codificar este sistema, estas son las lecciones que he aprendido:
- No subestimar los casos límite: el "31 del mes", los años bisiestos, los cambios de hora — cada caso parece raro individualmente, pero colectivamente afectan a miles de usuarios.
- Probar con datos reales: las pruebas unitarias no son suficientes. Hay que simular un año entero de ocurrencias y verificar visualmente.
- El modelo híbrido es el compromiso correcto: ni todo en la base de datos, ni todo calculado. La mezcla ofrece lo mejor de ambos mundos.
- La UX progresiva salva vidas: ocultar la complejidad detrás de niveles de detalle es el único enfoque viable para una aplicación de consumo masivo.
Si desarrollas una aplicación de productividad o un sistema de calendario, nunca subestimes los recordatorios recurrentes. Lo que parece una característica de 2 días puede fácilmente tomar 10.
Preguntas Frecuentes
¿Cuántos tipos de recurrencia soporta TAMSIV?
TAMSIV soporta cuatro tipos principales: diario, semanal, mensual y personalizado. El modo personalizado permite definir cualquier intervalo (cada N días, ciertos días de la semana, etc.) y cubre casos avanzados como "el último viernes del mes".
¿Se puede crear un recordatorio recurrente por voz?
Sí, de hecho, es uno de los puntos fuertes de TAMSIV. Puedes decir "recuérdame enviar el informe todos los lunes a las 9h" y la IA comprende automáticamente el tipo de recurrencia, el día y la hora. Solo tienes que validar para que el recordatorio sea creado.
¿Qué sucede si un recordatorio mensual cae en un día que no existe?
TAMSIV desplaza automáticamente el recordatorio al último día del mes. Por ejemplo, un recordatorio el día 31 se adelantará al 28 o 29 en febrero, y al 30 en abril, junio, septiembre y noviembre. Este es el comportamiento más intuitivo para el usuario.
¿Los recordatorios recurrentes funcionan con la gamificación?
Absolutamente. Cada vez que completas un recordatorio recurrente, ganas puntos de experiencia y alimentas tu racha diaria. Es una excelente manera de mantener una rutina productiva y mantenerte motivado a largo plazo.
¿Cómo modificar o eliminar una sola ocurrencia de un recordatorio recurrente?
Puedes modificar o eliminar una ocurrencia específica sin afectar a las demás. El sistema crea entonces una "excepción" para esa fecha. El resto de la serie continúa normalmente según la regla definida.