Comment implémenter une logique de paiement sans file d'attente externe avec Vercel Workflows

Séparation des étapes pour les environnements de production

Lorsque l'on manipule des fonctions serverless, on se heurte souvent au mur des limites de temps d'exécution. Vercel Workflows résout ce problème en transformant les fonctions asynchrones en processus capables de maintenir leur état. Ici, la clé est d'éliminer les éléments incertains, tels que les écritures en base de données ou les fonctions aléatoires, de la fonction orchestratrice. Tous les effets de bord doivent impérativement être confinés dans des blocs step.run pour éviter que le système ne s'emmêle.

Déclarez use workflow dans la fonction qui contrôle l'ensemble de la logique et contentez-vous d'y gérer le flux. Définissez les appels API réels ou les opérations de base de données comme des étapes indépendantes. Lors du passage à l'étape suivante, ne transmettez que les données nécessaires pour économiser sur les coûts de stockage des logs. Avec cette structure, même si une tâche échoue en cours de route, il n'est pas nécessaire de tout recommencer depuis le début. Il suffit de reprendre là où l'on s'est arrêté.

Logique d'idempotence pour éviter les doubles paiements

Dans les systèmes distribués, des erreurs réseau peuvent entraîner l'exécution en double d'une même étape. Dans un système de paiement, cela peut s'avérer désastreux. Vercel Workflows fournit un stepId unique pour chaque étape. Lors de l'intégration avec Toss Payments ou Stripe, l'utilisation de cet identifiant comme clé d'idempotence permet d'éviter les accidents de double facturation.

Intégrez dans votre code un pattern qui vérifie si une transaction a déjà été traitée avant d'écrire des données. Il suffit d'assigner l'ID extrait via getStepMetadata() aux en-têtes de requête du service externe. Concevez le système pour qu'il renvoie immédiatement une réponse s'il s'agit d'une transaction déjà traitée. Rien qu'en structurant correctement cet aspect, vous réduisez les appels API inutiles et économisez plus de 20 % sur les coûts d'infrastructure.

Gestion des tâches de longue durée sans timeout

Les fonctions serverless de Vercel s'arrêtent généralement après 1 à 15 minutes. Cependant, avec step.sleep, il est possible de gérer sans difficulté des tâches programmées s'étalant sur plusieurs jours. Lorsque cette fonction est exécutée, l'état du workflow est enregistré dans le stockage et la fonction s'arrête immédiatement. Aucun coût de calcul n'est facturé pendant l'attente.

Par exemple, si vous devez envoyer un e-mail d'enquête trois jours après la finalisation d'un paiement, une simple ligne await step.sleep('3 days') suffit. Comme il n'est plus nécessaire de gérer une crontab ou un planificateur séparé, vous gagnez environ deux heures de temps opérationnel par semaine. Les coûts liés à l'exécution d'un serveur 24h/24 disparaissent également.

Validation des workflows en local

Le cycle répétitif de déploiement et de modification freine la vitesse de développement. En utilisant les fonctionnalités de la Vercel CLI, vous pouvez tester vos workflows localement sans les mettre sur le cloud. Si vous devez recevoir des webhooks externes, utilisez un outil comme ngrok pour exposer votre hôte local à l'extérieur.

Lancez vercel dev et enregistrez l'URL générée par ngrok dans les paramètres de webhook de Stripe pour que votre code local reçoive les événements externes en temps réel. Pouvoir valider les scénarios d'échec avant le déploiement permet de doubler la vitesse de développement. Cela réduit aussi le temps perdu à cause d'erreurs de configuration des variables d'environnement.

Politique de tentative basée sur l'exponentiel backoff

Si des tentatives infinies se produisent à cause de limites de débit d'API ou de pannes réseau temporaires, la facture peut exploser. Il faut adapter la réponse selon la nature de l'erreur. Les erreurs permanentes, comme un échec d'authentification, doivent entraîner un arrêt immédiat, tandis que les problèmes temporaires, comme les pannes réseau, doivent être retentés après un certain délai.

Appliquez la formule de l'exponentiel backoff pour augmenter progressivement l'intervalle entre les tentatives :

$$Interval = InitialDelay \times 2^{Attempt}$$

Limitez le nombre maximal de tentatives en configurant maxRetries: 3 dans la fonction step.run. Le système se rétablit automatiquement, augmentant ainsi la disponibilité du service, tout en bloquant préventivement la facturation excessive due à des boucles infinies.

Coûts opérationnels et efficacité de l'infrastructure

Vercel Workflows offre par défaut 50 000 exécutions d'étapes pour le plan Pro. En cas de dépassement, le tarif est de 2,50 $par tranche de 100 000 étapes. Les coûts de stockage générés lors des attentes de longue durée sont très abordables, à 0,00069$ par Go-Heure.

Catégorie	Inclus dans Hobby/Pro	Tarif d'excédent
Étapes de Workflow	50 000 étapes	2,50 $par 100 000 étapes
Stockage de Workflow	720 Go-Heures	0,00069$ par Go-Heure
Fonction Serverless	1 000 Go-Heures	0,60 $ par Go-Heure

C'est incroyablement économique comparé aux efforts nécessaires pour construire et gérer soi-même une file d'attente de messages complexe. En combinant correctement la garantie d'idempotence et l'exponentiel backoff, vous pouvez assurer une fiabilité de niveau production sans la charge de la gestion d'infrastructure. Pour un développeur solo souhaitant se concentrer uniquement sur la logique métier, il n'y a pas de choix plus rationnel.