Mettre en œuvre un calendrier de rétention sous forme de tâches de suppression

Objectif

Transformer un calendrier de rétention écrit (par exemple : enregistrements de session 30 jours après la dernière activité, tickets de support deux ans après leur clôture) en tâches qui suppriment à temps, de manière vérifiable, sans interrompre le service. Quelles périodes conviennent à quelles données est une décision organisationnelle, qui ne relève pas de cette méthode.

Prérequis

Une table de rétention : une ligne par classe de données, avec le magasin, l'horloge qui déclenche le début de la période (création, dernière activité, clôture), la période et le responsable. Chaque table ou bucket contenant des données personnelles correspond à une ligne. Des horodatages à partir desquels la période peut être calculée (une colonne closed_at, et non un indicateur de statut sans date).

Étapes

1. Choisir le mécanisme par magasin. Tables partitionnées par le temps : supprimer ou détacher la partition expirée ; la documentation PostgreSQL indique que DROP TABLE ou ALTER TABLE DETACH PARTITION sur une partition est bien plus rapide qu'une opération en masse et évite la surcharge de VACUUM d'un DELETE en masse, que les deux nécessitent un verrou ACCESS EXCLUSIVE sur la table parente, et que DETACH PARTITION ... CONCURRENTLY ne nécessite qu'un verrou SHARE UPDATE EXCLUSIVE. Stockage d'objets : règles de cycle de vie ; la documentation Amazon S3 décrit des actions d'expiration qui suppriment les objets expirés pour le compte du titulaire du compte. Tout le reste : un DELETE ... WHERE clock < now() - interval par lots, avec une limite fixe de lignes par itération et une pause entre les itérations, la limite étant choisie selon la charge observée du magasin.
2. Écrire la tâche de manière idempotente et reprenable : chaque exécution sélectionne le prochain lot de lignes expirées, les supprime, enregistre le décompte et se termine ; une panne en cours d'exécution ne coûte rien.
3. Supprimer d'abord les dépendants, ou s'appuyer délibérément sur ON DELETE CASCADE et lister cette cascade dans la table de rétention.
4. Planifier la tâche avec un verrou, de sorte que deux instances ne s'exécutent jamais simultanément ; émettre à chaque exécution : le nombre de lignes examinées, le nombre de lignes supprimées, l'âge de la ligne restante la plus ancienne.
5. Alerter sur l'âge de la ligne restante la plus ancienne : si une ligne est plus ancienne que la période plus une marge de grâce, la tâche est défaillante, qu'elle signale ou non des erreurs.
6. Démarrer en mode simulation (dry-run) : compter ce qui serait supprimé, comparer avec l'attendu, puis activer.
7. Propager : les magasins dérivés (index de recherche, tables analytiques, caches) expirent soit selon la même période de leur propre chef, soit s'abonnent aux événements de suppression.

Résultat attendu

Chaque classe de données dispose d'une tâche ou d'une règle de cycle de vie, d'une métrique et d'une alerte ; l'âge de la ligne la plus ancienne reste inférieur à la période ; la rétention devient une propriété du système en fonctionnement plutôt que d'un document.

Limites et base de vérification

Les sauvegardes sont hors calendrier ; la propre rétention d'une sauvegarde borne la durée de survie des données supprimées. Les enregistrements sous conservation légale (hold) ont besoin d'un indicateur d'exemption par enregistrement que la tâche respecte ; quels cas en ont besoin n'est pas traité ici. Le comportement des verrous et du cycle de vie suit la documentation citée ; aucun chiffre de débit n'est revendiqué.