Une queue de message construite avec Postgres.

Projet prometteur mais assez récent donc à utiliser avec précaution.

Tout se fait en SQL:

-- creates the queue
SELECT pgmq.create('my_queue');

-- messages are sent as JSON
SELECT * from pgmq.send('my_queue', '{"foo": "bar1"}');

SELECT * FROM pgmq.read('my_queue', 30, 2);
-- or
SELECT pgmq.pop('my_queue');

Scaleway lance son service cloud de Message Queue!

C'est basé sur NATS.io qui est un message broker moderne et cloud native.

L'histoire de l'adoption de Kafka chez Cloudflare en tant que message bus inter-services.

Ils l'ont déployé pour optimiser le développement de leur architecture micro-service (découplage) mais aussi:

• réduire les silos de données
• rendre les communications inter-services plus claires
• avoir un format de communication auto-documenté

Pour cela, ils ont notamment développé un client Kafka interne qui abstrait la plupart de la configuration et de la logique compliqué.

Le schéma de communication n'est pas JSON ou Avro (ouf!) mais l'excellent Protobuf qui en plus d'avoir une taille réduite, assure le typage fort de chaque champ afin d'identifier les breakings changes.

Niveau observabilité, le plus important pour eux est le "lag", qui est le temps entre le dernier message produit et le dernier message lu.

Cette seule métrique permet d'identifier de nombreux problèmes:

• le consumer est down
• le consumer n'arrive pas à ingérer tous les messages
• un nombre inhabituel de messages est produit
• le consumer n'acquitte plus les messages

Bref, un super retour d'expérience et pleins de bons conseils pour construire son infrastructure applicative avec Kafka.

Le début de l'article explique très clairement le fonctionnement de Kafka avec une vulgarisation accessible à tous et des schémas.

Une bande dessinée qui explique les raisons d'utiliser un message broker comme Kafka et le fonctionnement de ce dernier.

(Merci Gaël pour le partage)

On parle souvent des comparaisons entre SQL et NoSQL mais cet article va plus loin en comparant les usages des 5 grandes familles de "Data Store"

• Base de données relationnelles (e.g. PostgreSQL)
• Base de données non-relationnelles (e.g. MongoDB)
• Base de données clé/valeur (e.g. Redis)
• Moteur de recherche (e.g. Elasticsearch)
• File de messages (e.g. Kafka)

Un système de queing entièrement basé sur Redis.

Ils proposent toutes les fonctionnalités dont on a besoin:

• multi-queue producers et consumers
• garantie du delivery unique
• expiration des messages
• rate limiting

Un très bon retour d'expérience sur RabbitMQ pour un système de queuing robuste, scalable et surtout maintenable.

• Réalisez une expertise de votre solution pour en comprendre les limites (2000~3000€ bien investis)
• Configurez le cluster pour qu'il mette en pause les nœuds de la partition minoritaire en cas de désynchronisation réseau

RabbitMQ reste une très bonne alternative à la grosse usine à gaz Kafka qu'on sort à toutes les sauces.

Une alternative à Kafka, RabbitMQ et autre système de message queue.

Celui la est très moderne, portée par la Cloud Native Computing Foundation (CNCF), avec de super fonctionnalités supplémentaires:

• rejouer les messages avec le timing originel: parfait pour rejouter les messages de la prod et staging
• acquittement unitaire des messages
• démarrer un consumer à une date précise

Plus d'info 👉 https://docs.nats.io/nats-concepts/jetstream/consumers