NATS et JetStream : messaging cloud-native simple et performant

Kafka domine la conversation dès qu'on parle de streaming d'événements à grande échelle, et RabbitMQ reste le réflexe pour les files de messages classiques. Entre les deux, ou plutôt à côté, NATS occupe une place que beaucoup d'équipes redécouvrent : un système de messaging très léger, simple à opérer, qui couvre à la fois le pub/sub temps réel et, depuis l'ajout de JetStream, la persistance et le streaming durable.

Cet article présente NATS et JetStream (architecture, primitives), les compare à Kafka et RabbitMQ sur les axes qui pèsent en pratique, détaille un déploiement cluster type et liste les cas d'usage où NATS prend le pas sur les alternatives.

• Qu'est-ce que NATS
• Les primitives : subjects, queue groups, requests
• JetStream : persistance et streaming
• Comparaison NATS vs Kafka vs RabbitMQ
• Déploiement d'un cluster
• Sécurité : NKeys, JWT, accounts
• Cas d'usage pertinents

NATS est un système de messaging open source distribué sous licence Apache 2.0, projet diplômé de la Cloud Native Computing Foundation (CNCF). La dernière version stable du serveur (nats-server) est la v2.14.0, publiée le 30 avril 2026.

Conçu à l'origine en 2010 par Derek Collison (ancien de TIBCO Rendezvous), NATS vise un objectif unique : transporter des messages le plus simplement et le plus vite possible. Le serveur tient en un binaire Go d'environ 20 Mo, démarre en une seconde, ne nécessite aucune dépendance externe pour le mode pub/sub.

L'écosystème compte plus de 40 implémentations clientes officielles (Go, Java, Python, Node.js, Rust, .NET, C, Ruby, Elixir, Swift…). Le serveur a été audité par Trail of Bits.

Trois éléments structurent le projet :

1. Le pub/sub par défaut, avec garanties at-most-once. Pas de persistance, latences inférieures à la milliseconde sur un cluster local.
2. JetStream pour la durabilité. Couche optionnelle qui ajoute la persistance disque, le replay, et les garanties at-least-once / exactly-once.
3. Le multi-tenancy via accounts. Plusieurs tenants isolés sur un même cluster, sans déployer plusieurs instances.

NATS organise les messages autour de subjects, des chaînes hiérarchiques séparées par des points : orders.eu.fr.created, metrics.app01.cpu, auth.login.success. Les abonnés peuvent souscrire à des subjects précis ou à des wildcards (* pour un segment, > pour le reste).

# Publier un message
nats pub orders.eu.fr.created '{"id":42,"amount":99.9}'

# Souscrire à un wildcard
nats sub 'orders.eu.>'

# Souscrire avec queue group (load balancing)
nats sub 'orders.eu.>' --queue order-workers

Les queue groups sont la primitive de load balancing : tous les abonnés qui partagent le même nom de queue group reçoivent une part des messages, comme un consumer group Kafka mais sans persistance par défaut.

Les requests ajoutent un pattern request/reply natif : le client publie sur un subject avec un reply subject, un service répond. Permet de construire du RPC léger sans HTTP ni gRPC.

# Service qui répond sur 'svc.echo'
nats reply 'svc.echo' 'reply: {{.Request}}'

# Client qui interroge
nats request svc.echo "hello"

Avant 2020, NATS était purement at-most-once, sans persistance. Pour les cas qui exigeaient des garanties (file durable, replay, audit), il fallait passer à STAN (NATS Streaming). STAN a été déprécié au profit de JetStream, intégré directement au serveur.

JetStream introduit deux concepts :

Stream. Une suite ordonnée de messages stockée sur disque ou en mémoire, alimentée par des subjects. Un stream peut capturer plusieurs subjects (orders.>, payments.>) et appliquer une politique de rétention (taille, durée, nombre).

Consumer. Un état de consommation d'un stream, avec gestion des acks et du redelivery. Plusieurs consumers peuvent lire le même stream à des positions différentes.

# Créer un stream qui capture orders.>
nats stream add ORDERS \
  --subjects 'orders.>' \
  --retention limits \
  --max-age 7d \
  --storage file \
  --replicas 3

# Créer un consumer durable
nats consumer add ORDERS order-processor \
  --filter 'orders.eu.>' \
  --ack explicit \
  --deliver all

JetStream gère la réplication via Raft : un stream --replicas 3 est répliqué sur trois nœuds, avec un leader élu par Raft. Perte d'un nœud : élection automatique d'un nouveau leader, pas d'interruption pour les producteurs/consommateurs.

Le positionnement diffère sur des axes précis :

NATS prend l'avantage quand la simplicité opérationnelle prime, pour des charges où la rétention longue n'est pas centrale. Kafka reste la référence pour les pipelines de données analytiques à très haut débit avec rétention de plusieurs jours/semaines. RabbitMQ garde sa pertinence pour les protocoles AMQP, MQTT, STOMP et les patterns de routage complexes (topic exchange, headers exchange).

Le déploiement minimal d'un cluster NATS à trois nœuds tient en un fichier de configuration par nœud. Exemple nats-server.conf du nœud A :

server_name: nats-a
listen: 0.0.0.0:4222

cluster {
  name: prod-cluster
  listen: 0.0.0.0:6222
  routes: [
    nats://nats-b:6222
    nats://nats-c:6222
  ]
}

jetstream {
  store_dir: /var/lib/nats/jetstream
  max_memory_store: 1G
  max_file_store: 50G
}

http_port: 8222

Lancer le serveur :

nats-server -c /etc/nats/nats-server.conf

Ports utilisés :

• 4222/tcp : protocole client NATS.
• 6222/tcp : communication intercluster.
• 8222/tcp : monitoring HTTP (/varz, /streamz, /jsz).

Une fois les trois nœuds démarrés, le cluster est formé automatiquement, JetStream peut créer des streams --replicas 3 répartis sur les trois nœuds.

NATS implémente un modèle de sécurité moderne basé sur Ed25519. Trois niveaux d'identité :

• Operator : autorité racine du cluster.
• Account : tenant logique. Chaque account a son propre namespace de subjects, ses propres permissions, son propre quota JetStream.
• User : compte client à l'intérieur d'un account.

Chaque entité possède une paire de clés Ed25519 (NKey) et un JWT signé qui décrit ses permissions. Les utilisateurs s'authentifient en présentant leur JWT, le serveur valide la signature contre la chaîne operator → account → user.

# Créer un operator, account, user
nsc add operator --create-system-account SYS prod-op
nsc add account --name appA
nsc add user --name service-a --account appA \
  --allow-pub 'orders.eu.>' --allow-sub 'orders.eu.>'

Pour les déploiements simples, la configuration peut se limiter à des comptes statiques dans le fichier de config. Pour un cluster multi-tenant en production, le pattern recommandé est nsc + résolution via account_resolver (dossier local ou serveur HTTP).

NATS prend l'avantage dans plusieurs contextes.

Communication interservices à faible latence

Pour un ensemble de microservices qui s'échangent des notifications, des commandes, des events de domaine, NATS offre une latence sub-milliseconde et une simplicité d'opération qu'aucun broker plus lourd ne peut concurrencer. Le pattern request/reply remplace souvent un appel HTTP synchrone avec une meilleure découplabilité.

Edge et IoT

Le serveur léger (~20 Mo) tourne sur du matériel contraint. Pour du déploiement edge avec des centaines ou milliers de nœuds qui poussent des métriques ou des events vers un central, NATS scale sans difficulté. Les leaf nodes permettent de fédérer un cluster edge avec un cluster central via un seul lien sécurisé.

Buffer durable léger

Quand on a besoin d'un buffer durable mais que Kafka est démesuré (volume modeste, équipe sans expertise JVM), JetStream offre la persistance sans la complexité opérationnelle. Configuration minimale, pas de cluster ZooKeeper/KRaft à maintenir, réplication Raft transparente.

Plateforme d'événements multi-tenants

Le modèle accounts + JWT permet à un opérateur unique d'héberger plusieurs équipes ou clients sur le même cluster avec une isolation stricte des subjects et des quotas. Pas besoin de déployer un broker par tenant.

Pas de Kafka Connect équivalent. L'écosystème de connecteurs source/sink prêts à l'emploi est moins riche que celui de Kafka. Pour ingérer ou exporter vers PostgreSQL, S3, Elasticsearch, on s'appuie sur des projets tiers (par exemple Benthos/Bento) ou des intégrations custom.

Schémas non intégrés. Pas de Schema Registry natif. Pour de la gouvernance de schéma, on conserve un registre externe (Apicurio, Confluent Schema Registry).

Rétention longue moins efficiente que Kafka. Pour des charges qui réclament des téraoctets de rétention sur des semaines avec des replays massifs, Kafka reste plus adapté.

Modèle de partitionnement différent. JetStream n'a pas la notion de partition au sens Kafka. L'ordering est strict dans un stream, mais la parallélisation côté consumer passe par le filtrage de subjects ou les queue groups.

• Kafka KRaft : monitoring d'un cluster moderne
• RabbitMQ en haute disponibilité
• Redis cluster pour le cache distribué
• OpenTelemetry et l'observabilité moderne
• Architectures edge avec K3s, Ceph et GitOps

• Dépôt nats-io/nats-server, code, releases, version v2.14.0
• Documentation NATS, concepts, déploiement, opérations
• JetStream documentation, streams, consumers, réplication Raft
• NATS by Example, patterns par langage
• Trail of Bits security audit (2025), audit indépendant

NATS n'essaie pas de remplacer Kafka sur ses terres ni de battre RabbitMQ sur le routage AMQP avancé. Il propose une troisième voie : un broker simple, rapide, multi-tenant, complété par JetStream pour la persistance quand on en a besoin. Pour la majorité des architectures microservices ou edge qui n'ont pas besoin de stocker des semaines d'événements, c'est un choix pragmatique qui réduit la complexité opérationnelle sans sacrifier les garanties essentielles.