Dejar que los datos expiren a propósito: el TTL como decisión de arquitectura
No todos los datos merecen vivir para siempre. Diseñar la expiración desde el modelo de datos, en vez de tratarla como un job de limpieza posterior, cambia por completo el perfil de escala de un sistema.
Hay un reflejo casi universal en el diseño de bases de datos: guardar todo, indefinidamente, "por si acaso se necesita después". Para datos de negocio con valor duradero (una transacción, un pedido, un contrato) ese reflejo tiene sentido. Para otra categoría de datos, muy distinta, ese mismo reflejo es la raíz de un problema de escala que aparece meses después, silenciosamente.
El tipo de dato que no debería vivir para siempre
Pensemos en la posición GPS de un vehículo, reportada cada pocos segundos. Ese dato tiene un valor altísimo en el momento en que se genera: alguien necesita saber dónde está el vehículo ahora. Ese mismo dato, seis meses después, casi nunca tiene valor operativo. Nadie va a consultar "dónde estaba este conductor a las 3:14 pm de un martes hace medio año" salvo en casos de auditoría muy específicos, que probablemente ya se resolvieron con un resumen agregado, no con cada punto GPS individual.
Guardar ese dato para siempre no es prudencia, es acumular volumen sin valor proporcional. Y ese volumen tiene un costo real: índices más grandes, consultas más lentas, backups más pesados, y una base de datos que crece de forma indefinida en tamaño aunque su valor útil no crezca en absoluto.
Por qué "borrar con un job después" no es lo mismo que diseñar con TTL
La respuesta ingenua es programar un job de limpieza que borre datos viejos periódicamente. Funciona, pero introduce una asimetría rara: durante la ventana entre que el dato deja de ser útil y el job se ejecuta, sigue ocupando espacio y sigue siendo parte de cualquier consulta que no filtre explícitamente por fecha. Además, ese job es una pieza más de infraestructura que puede fallar, quedarse corriendo más tiempo del esperado bajo volumen alto, o simplemente olvidarse con el tiempo.
Diseñar con TTL desde el principio, usando un mecanismo de expiración nativo de la base de datos en lugar de un proceso externo, cambia la naturaleza del problema: la expiración deja de ser una tarea de mantenimiento y se convierte en una propiedad del dato mismo, declarada una vez, ejecutada de forma consistente por el motor de base de datos, sin depender de que un job externo se acuerde de correr.
La pregunta de diseño real
La decisión que importa no es técnica ("¿cómo implemento TTL?"), es de modelado: ¿este dato representa un evento efímero de operación, o representa un hecho de negocio que necesita persistir? La posición GPS de hace seis meses es lo primero. El pedido que se entregó hace seis meses es lo segundo. Confundir ambas categorías, y aplicarles la misma política de retención por defecto, es donde nace el problema: o se acumula basura operativa indefinidamente, o se corre el riesgo de borrar accidentalmente algo que sí tenía valor de negocio duradero.
La lección
Un sistema bien diseñado no trata "cuánto tiempo vive un dato" como una decisión operativa tomada después, por un equipo de infraestructura preocupado por el tamaño del disco. La trata como una decisión de producto, tomada en el mismo momento en que se modela la entidad, con la misma seriedad que se le daría a definir sus campos o sus relaciones. Los datos que expiran por diseño no son datos a los que se les prestó menos atención. Son datos a los que se les prestó la atención correcta.