Comment Plaid a multiplié par 30 le parallélisme de Node

Plaid est un service qui lit les informations de solde des utilisateurs auprès des banques et les fournit à l’extérieur via une API bancaire unifiée.

Après avoir exploité 4 000 workers Node sans parallélisation, l’entreprise est passée à un traitement parallèle et a économisé 300 000 $ par an.

L’article présente de manière claire les approches testées étape par étape pour appliquer ce changement sans erreur.

• Ajout de métriques dans Prometheus : taille du heap V8, GC, latence des tâches

• Création d’un tableau de bord Grafana pour mesurer l’effet du traitement parallèle

• Utilisation des feature flags de LaunchDarkly pour ajuster l’effet du traitement parallèle sans redéploiement

• Génération de flamegraphs en production pour mesurer le temps CPU

Après le déploiement réel, l’enquête et les corrections ont continué de façon itérative.

• Augmentation de la taille maximale du heap de Node

• Suppression du goulot d’étranglement S3 : augmentation de maxSockets, que le client S3 réduisait à 50, jusqu’à 20480

• Amélioration de la vitesse de sérialisation JSON : remplacement de bfj par JSONStream

• Réduction du nombre d’exécutions du GC en définissant la taille du semi-space

• Optimisation du temps CPU en modifiant la méthode de logging qui utilisait beaucoup de regex

[chusouk]

Oh oh