TL;DR
NATS est un système de messaging open-source (Apache 2.0) qui fait trois choses dans un seul binaire Go d’environ 5 Mo : du pub/sub et request-reply avec Core NATS, du streaming durable avec JetStream, et de la connectivité multi-topologie (leaf nodes, super-clusters, gateways, MQTT bridge). Il est adopté en production par Walmart, Mastercard, Tinder et VMware Tanzu. Cette vidéo et ce chapitre du tutoriel en donnent une vue d’ensemble avant d’entrer dans la pratique.
La video de reference
La vidéo NATS – 001. Introduction, c’est quoi ?? (2 min 46) est le premier épisode de la playlist NATS – Tutorials de la chaîne xavki. Elle pose le cadre de la série et répond à la question centrale : qu’est-ce que NATS et pourquoi l’utiliser ?
Le dépôt d’accompagnement est disponible sur GitLab à l’adresse https://gitlab.com/xavki/tutorials-nats (48 chapitres, slides au format mdp et code Python avec nats-py).
NATS, c’est quoi exactement ?
NATS est un système de messaging open-source né en 2011 chez Apcera (créé par Derek Collison) pour les besoins de Cloud Foundry. Il a été réécrit en Go en 2015 et est devenu un projet **CNCF graduated** en 2018.
Concrètement, NATS ne fait pas "qu’une seule chose". Un seul processus nats-server embarque trois couches :
- Core NATS — Un bus de messaging at-most-once : pub/sub, request-reply, queue groups. Pas de persistance, pas de garantie de délivrance — rapide, simple, efficace.
- JetStream — Une couche de streaming durable at-least-once intégrée au même binaire. Streams, consumers push/pull, KV store, Object Store, work queues, déduplication.
- Connectivité — Leaf nodes pour relayer des sites distants (edge, IoT, usines) vers un hub central, super-clusters pour fédérer plusieurs clusters, gateways pour le multi-DC, et un bridge MQTT pour les clients IoT.
Le modèle de communication repose sur les subjects : des chaînes dot-separated comme orders.eu.created. Les publishers envoient des messages sur des subjects, les subscribers expriment leur intérêt sur ces mêmes subjects (avec support des wildcards * et >). Pas d’exchanges, pas de bindings, pas de DLX — le routage est déterminé par le nom du subject.
Pourquoi NATS existe
Le problème que NATS résout est celui de la fragmentation de la communication dans les systèmes distribués. Quand une architecture grandit, les services se déplacent entre poste de développement, VM, Kubernetes, cloud, edge. Le RPC point-à-point devient fragile. Les équipes se retrouvent à utiliser quatre produits différents pour le pub/sub, le file d’attente, le streaming et le KV.
NATS répond en proposant une fabric connective unique :
- Communication indépendante de la localisation via les subjects
- Modèle async-first avec pub/sub, request-reply et streaming dans le même serveur
- Un seul binaire léger au lieu d’une pile de brokers et de sidecars
Le README du dépôt précise que la série suit une progression pédagogique en 8 blocs, de la découverte jusqu’au déploiement Kubernetes et à l’intégration Redpanda Connect.
Le vrai problème que NATS résout
Au-delà du simple "c’est un broker de messages", le vrai problème que NATS attaque est celui de la complexité opérationnelle. Là où Kafka a besoin de Zookeeper/KRaft, d’un JVM tuning, et d’un cluster dédié, NATS tourne avec un binaire Go de 5 Mo. Pas de JVM, pas de ZooKeeper, pas de stockage externe pour JetStream.
Cette simplicité opérationnelle a un impact direct sur le type de projets qui peuvent adopter du messaging fiable :
- Une startup peut déployer NATS sans ingénieur infrastructure dédié
- Une équipe edge peut embarquer NATS dans un Raspberry Pi
- Un groupe Kubernetes peut ajouter NATS comme sidecar sans réarchitecturer le cluster
Les slides du chapitre 01-introduction insistent aussi sur la topologie flexible — leaf nodes pour l’edge, gateways pour le multi-DC, super-clusters pour la scalabilité horizontale. Cette flexibilité est rare dans un seul outil.
Notions et concepts
Subjects
Un subject est une chaîne dot-separated : orders.eu.created. Les publishers envoient des messages sur un subject. Les subscribers s’abonnent à un subject. Le serveur achemine les messages en faisant correspondre les abonnements. Les wildcards * (un segment) et > (tout le reste) permettent des abonnements flexibles.
Contrairement à RabbitMQ (exchanges + bindings + queues) ou Kafka (topics + partitions + consumer groups), le subject EST à la fois la route et le filtre. La conception des subjects devient donc un élément central de l’architecture.
Core NATS vs JetStream
Core NATS est le mode par défaut : pas de persistance, livraison at-most-once. Idéal pour les métriques temps réel, les notifications, les signaux de service. JetStream ajoute la persistance, le replay, les accusés de réception (ack/nak/term), les flux durables, le KV store et l’Object Store. Les deux coexistent sur les mêmes subjects — on commence simple et on ajoute de la durabilité là où le workflow le nécessite.
Clients officiels
NATS n’est pas un outil "Go uniquement". Les clients officiels couvrent Go, Java, JavaScript, TypeScript, Python, C#, C, Ruby, Elixir, Rust — avec plus de 40 implémentations communautaires. Le modèle mental (subjects, publish, subscribe, request, JetStream) est le même dans tous les langages.
Comparaisons : NATS vs les alternatives
Le chapitre `03-nats-vs-alternatives` est dédié à la comparaison détaillée, mais voici un aperçu du positionnement :
| Produit | Point fort | NATS gagne quand… |
|---|---|---|
| Kafka | Event log / analytics / gros écosystème | On veut simplicité, latence faible, edge et petite empreinte ops |
| RabbitMQ | AMQP / routage flexible par exchanges | On veut un routage plus simple et des opérations plus légères |
| Redis Streams | Déjà du Redis en production | Le messaging devient un besoin plateforme, pas une brique accessoire |
| Apache Pulsar | Streaming durable + tiered storage | On ne veut pas de la complexité BookKeeper |
| Mosquitto / EMQX | Pure IoT MQTT | Le traffic IoT doit aussi alimenter des services backends + JetStream |
| SNS/SQS / PubSub | Cloud managé vendor-specific | On veut la portabilité cloud + on-prem |
Quand utiliser NATS
- Service-to-service messaging sans ops lourde
- Need de request-reply + events + durable replay dans la même stack
- Workloads répartis entre cloud, on-prem, usines, edge
- Isolation multi-tenant avec accounts et auth décentralisée
- Chemin progressif du pub/sub simple au JetStream durable
Quand éviter NATS
- Besoin d’un écosystème Kafka-like pour l’analytics
- Dépendance stricte à AMQP ou aux semantics d’exchange RabbitMQ
- Déjà profondément lié à un produit de messaging cloud propriétaire
Commandes et premier setup
Les slides du chapitre 01 listent plusieurs façons d’installer NATS :
# macOS
brew install nats-server nats
# Linux (Debian/Ubuntu)
apt-get install nats-server
# Docker
docker run nats:latest -js
# Python SDK
uv add nats-py
# ou
pip install nats-pyPour lancer un serveur de développement avec JetStream et le monitoring HTTP :
nats-server -js -m 8222Le monitoring est alors accessible sur http://localhost:8222 avec les endpoints /varz, /connz, /subsz, /jsz.
Le dépôt du tutoriel utilise mdp pour afficher les slides dans le terminal :
# Installer mdp
brew install mdp
# Afficher les slides du chapitre 01
mdp 01-introduction/slides.mdLiens utiles
- Dépôt du tutoriel : https://gitlab.com/xavki/tutorials-nats
- Playlist NATS – Tutorials : https://www.youtube.com/playlist?list=PLn6POgpklwWp8hW7QMmRQlzzirO0Q2AKx
- Vidéo de l’épisode : https://www.youtube.com/watch?v=ZHbJO6VRRK4
- Site officiel NATS : https://nats.io
- Documentation : https://docs.nats.io
- Exemples interactifs : https://natsbyexample.com
- Client Python : https://github.com/nats-io/nats.py
- CLI NATS : https://github.com/nats-io/natscli
- Helm chart Kubernetes : https://github.com/nats-io/k8s
- Chaîne Synadia (talks techniques) : https://www.youtube.com/@SynadiaCommunications
- Blog NATS : https://nats.io/blog
- Slack communauté : https://slack.nats.io
- Stack Overflow : https://stackoverflow.com/questions/tagged/nats.io
- GitHub xavki (sommaire des vidéos) : https://bit.ly/2P5x8Xj
FAQ
NATS est-il gratuit ? Oui. Le serveur et les clients officiels sont sous licence Apache 2.0. Synadia propose une offre managée (NGS) pour ceux qui ne veulent pas opérer leur propre cluster.
Quelle est la différence entre NATS et NATS JetStream ? Core NATS est le mode sans persistance (at-most-once). JetStream est une extension intégrée qui ajoute la persistance, le replay, les accusés de réception et les flux durables (at-least-once). Les deux tournent dans le même binaire.
NATS peut-il remplacer Kafka ? Dans certains cas oui, dans d’autres non. NATS est plus simple, plus léger et plus rapide sur la latence. Kafka a un écosystème analytics plus riche (Kafka Connect, Kafka Streams, ksqlDB). Le chapitre 03 du tutoriel compare les deux en détail.
Quels langages sont supportés par NATS ? Les clients officiels couvrent Go, Java, JavaScript, TypeScript, Python, C#, C, Ruby, Elixir, Rust. Plus de 40 implémentations communautaires existent.
Où trouver de l’aide ? Le Slack NATS est très actif. La documentation officielle est complète. Le forum Discord de xavki peut aussi aider sur la mise en pratique.
Conclusion
NATS est un système de messaging qui se distingue par sa simplicité opérationnelle, sa polyvalence (Core NATS + JetStream dans le même binaire) et sa flexibilité topologique (leaf nodes, super-clusters, gateways, MQTT). Adopté en production par Walmart, Mastercard et Tinder, il prouve sa robustesse à l’échelle.
Ce premier épisode plante le décor. Le prochain chapitre `02-notions-definitions` définira chaque concept : subject, message, connection, subscription, queue group, wildcards, request-reply, headers, JetStream stream, consumer, durables, ack, KV, ObjectStore, NKEYS, JWT, account, leaf node, super-cluster, gateway. La suite de la playlist permet d’apprendre par la pratique avec des slides et du code Python exécutable.
Pour suivre le tutoriel : git clone git@gitlab.com:xavki/tutorials-nats.git && cd tutorials-nats && mdp 01-introduction/slides.md