Fondation de la plateforme

Moteur de tâches asynchrones

Modèle file/travailleur basé sur BullMQ avec clés d'idempotence, politiques de réessai, files de lettres mortes et état des tâches accessible — conçu pour l'inspection opérationnelle.

Pourquoi cela compte pour les acheteurs d'entreprise

Les opérations longues (imports en masse, génération d'horaires, clôtures de cycles QA, exports) doivent être fiables, observables et idempotentes. Le moteur de tâches de FrontLine est bâti sur BullMQ avec des politiques de réessai explicites, des files de lettres mortes pour les échecs ayant épuisé les réessais, et un inspecteur de tâches pour que votre équipe ops voie ce qui s'exécute, ce qui a échoué et ce qui est en attente.

Comment c'est implémenté

Conçu pour que les opérateurs voient ce qui s'exécute, ce qui a échoué, ce qui est en attente

Les tâches sont mises en file via un contrat typé par genre de tâche, avec une clé d'idempotence obligatoire. Le service worker consomme depuis les files nommées avec une concurrence configurée. Chaque genre déclare des paramètres de réessai (tentatives max, stratégie de retrait) et un délai. Les échecs au-delà des réessais aboutissent dans une DLQ pour inspection. L'état, le pourcentage de progression et le résultat de la tâche sont interrogeables via API. Redis fonctionne en mode noeviction pour que les tâches en file ne puissent pas être silencieusement perdues sous pression mémoire.

Capacités

Ce qui est couvert dès le départ

Contrats de tâches typés avec clés d'idempotence

Concurrence et limitation de débit par file

Retrait exponentiel avec tentatives max configurables

File de lettres mortes avec UI d'inspection

Machine d'état de tâche exposée au consommateur API

Webhook sur achèvement / échec

Politique Redis noeviction — aucune perte silencieuse sous pression mémoire

Événement d'audit émis à la soumission et à l'achèvement

Standards et conformité

Artefacts prêts pour l'audit sur lesquels vos évaluateurs peuvent s'appuyer

SOC 2 Type II — contrôles de disponibilité et de fiabilité
Politiques de réessai documentées par genre de tâche
Rétention DLQ par défaut de 30 jours
Manuels opérateur pour les modes d'échec courants

FAQ des achats

Ce que les évaluateurs sécurité et conformité demandent vraiment

Que se passe-t-il si un worker tombe en panne en cours de tâche ?+

La tâche est retournée à la file et reprise par un autre worker. Les clés d'idempotence empêchent la double écriture lors d'une exécution répétée.

Pouvons-nous voir quelles tâches s'exécutent ?+

Oui. L'UI d'admin de la plateforme expose la profondeur par file, les tâches en vol avec progression et la file de lettres mortes. Les points d'accès API exposent les mêmes données.

Les soumissions de tâches sont-elles auditées ?+

Oui — chaque soumission émet un événement d'audit avec l'acteur, le hash de la charge utile et la clé d'idempotence. L'achèvement émet un événement de suivi avec le statut.

Comment gérez-vous les tâches bloquées ?+

Chaque genre de tâche a un délai déclaré. Le dépasser marque la tâche comme échouée et déclenche un réessai selon la politique configurée. Les opérateurs peuvent remettre en file manuellement depuis la DLQ.

Présentez ceci à votre équipe sécurité

Nous partageons les aperçus de sécurité, le DDL des politiques RLS, les schémas d'événements d'audit, et l'avancement SOC 2 sur demande. Réservez une revue de sécurité de 30 minutes avec les fondateurs.

Réserver une revue de sécurité Retour à Atlas