Choisir une technologie de file d’attente avec Postgres

• Les files d’attente Postgres sont intéressantes, mais si elles ne sont pas dominantes, c’est à cause de l’idée largement répandue que d’autres technologies de queue offrent une plus grande scalabilité
• Des entreprises comme webapp.io ont choisi des files d’attente Postgres en privilégiant la simplicité opérationnelle, la maintenabilité et la familiarité plutôt que la scalabilité
• Composants d’une technologie de file d’attente Postgres
  • notifier et écouter les nouvelles tâches (pub/sub) ainsi que l’exclusion mutuelle (row locks)
  • ces deux éléments sont disponibles depuis Postgres 9.5, sorti en 2016
• L’auteur réfute l’idée répandue dans l’industrie selon laquelle utiliser Postgres de cette manière serait un « hack », et soutient que Postgres n’est pas une technologie de queue au rabais
• Des outils de queue comme Redis, Apache Kafka, RabbitMQ et Amazon SQS ont traditionnellement été choisis pour traiter les tâches de longue durée
• Critique de l’obsession du secteur technologique pour la « taille à l’échelle », au prix de la simplicité, de la facilité de maintenance et de la réduction de la charge cognitive des développeurs
• L’auteur propose, lors des choix technologiques, de prendre en compte les technologies déjà utilisées et bien comprises
• Il recommande de choisir par défaut une « technologie ennuyeuse » déjà en place et bien maîtrisée
• Présentation du concept de « construire sa porte de sortie », c’est-à-dire que le code applicatif chargé du traitement des tâches doit être indépendant de la queue
• L’auteur conclut en encourageant les autres à envisager une technologie de queue avec Postgres et à faire d’une « technologie ennuyeuse » leur choix par défaut

[GN⁺]

Avis Hacker News

• La simplicité, la persistance et la tolérance aux pannes de Kafka sont reconnues, mais sa nature distribuée peut ajouter de la complexité dans la plupart des cas d’usage.
• Une file Postgres peut remplacer une file Redis, mais pas une file SQS.
• Postgres a été utilisé pour traiter plus de 400 millions d’événements depuis la mise en service d’un système, avec environ 1 million d’événements traités par jour.
• Utiliser une table ordinaire avec SELECT FOR UPDATE SKIP LOCKED est une approche simple qui fonctionne avec tous les frameworks ORM/Query DSL.
• Le principal inconvénient de l’utilisation de LISTEN/NOTIFY pour faire de PostgreSQL un bus pub/sub est que LISTEN est une fonctionnalité de session, donc incompatible avec le pooling de connexions au niveau des instructions.
• Utiliser Postgres comme file applicative présente l’avantage de la transactionnalité, ce dont bénéficient les tâches asynchrones planifiées.
• Postgres peut monter en charge pour les files, mais il est plus simple et plus adapté de mettre en place SQS ou une autre stack de files sur AWS, GCP ou Azure.
• Postgres a exécuté des benchmarks à 1200 jobs/s sur des instances github CI, puis est monté à 5000 jobs/s avec des workers supplémentaires.
• Avec Oban d’Elixir, Postgres a servi à traiter, un par un, des centaines de milliers à des millions de tâches quotidiennes, avec des sémantiques transactionnelles éprouvées et pratiques autour des tâches de fond.
• Une implémentation ayant traité 47M de tâches met en avant les avantages d’un stockage durable avec des index pour implémenter des schémas coûteux comme SKIP LOCKED pour VACUUM, les tâches différées, les réessais, les mises à jour d’état et le mode « au moins une fois ».