Courtiers en communications

1) Pourquoi les courtiers en messages

• Tamponner et lisser les pics, backpresher.
• Mise à l'échelle en lecture/écriture indépendamment.
• Observabilité et reproduction (replay) des événements.
• Modèles architecturaux : event-driven, CQRS, event sourcing, outbox/inbox.

2) Modèles et termes de base

2. 1 Kafka (modèle logique)

La topique → les lots (logs ordonnés) → les offsets chez les consumers.
Consumer Group : parallélisme de lecture, équilibrage des lots.
Rétention en temps/volume ; compaction par clé.
Sémantique : minimum - at-least-once, dans les réglages - effectively exactly-once (producteurs idempotent + transactions).
Ordre : garanti à l'intérieur du lot.

2. 2 NATS (sujets/subjects, faible latence)

Subject (thème) avec hiérarchie et wyldcarts ('foo.', 'foo. >`).
Modes : pub/sub, queue-groups (fan-out avec distribution de travail), request-reply (RPC rapide).
Core NATS est une latence éphémère et ultra-basse ; JetStream est la persévérance/rétention/répétition.
Ordre : le meilleur effort, sans garantie mondiale forte ; avec JetStream - ordre sur la bande, mais il est possible de réorganiser rarement en cas de défaillance.

3) Sémantique de livraison et cohérence

L'idempotence et le dedup sont la responsabilité de l'application/bleu, même avec « exactly-once » à Kafka.

4) Ordre, lot et clés

Kafka

La sélection de la clé de message détermine le lot → l'ordre local fort.
Ключи: `aggregate_id`, `tenant_id`, `order_id`. Évitez les clés chaudes.
Équilibre : N lots ≈ niveau de parallélisme de lecture.

NATS

Chez Core, l'équilibre fait queue-groupe.
Dans JetStream Stream est chardiné par subjects ; l'accent est mis sur le fan-out/fan-in large avec peu de retard.

5) Rétention, repli et compaction

Kafka

Retention: `retention. ms/bytes`.
Compaction : stocke la « dernière valeur par clé » (convient pour les snapshots/caches/sags).
Replay : n'importe quel consumer peut « tirer » des offsets.

JetStream

Streams : backends de fichiers/memory, stratégie de stockage temporel/octets/kol-woo de messages.
Consumers : pull/push, durable/ephemeral, filtre par sous-préfixe.
Replay : redelivery ou lecture depuis le début/offset-like (sequence).

6) Transactions, outbox et cohérence

Kafka

Idempotent Producer (`enable. idempotence = true ') : protection contre les prises.
Transactions : enregistrement atomique de plusieurs lots + commit consumer-offsets → modèle read-process-write sans « trous ».
Transactional Outbox : enregistrement de l'événement d'entreprise et de la ligne d'outbox dans une transaction OBD, le worker publie dans Kafka.

NATS

Il n'y a pas de transactions « inter » comme dans Kafka ; utilisez outbox/inbox et des consumers idempotent (clés, dedup store).

7) RPC et demande-réponse

Kafka pour RPC est inconfortable (overhead élevé, ordre/réponses plus difficiles). Utilisez des commandes/événements asynchrones.
NATS : idéal pour request-reply (milisecondes, corollation, timaoutes).

go resp, err:= nc. Request("profile. get", []byte(`{"id":42}`), 200time. Millisecond)

8) Exploitation et topologie

8. 1 Kafka

Cluster : courtiers + ZooKeeper (avant les anciennes versions) ou KRaft (nouvelle métadonnées).
Réplication : RF≥3 par zone, ISR/contrôleurs.
Multiregion : MirrorMaker 2/Cluster Linking ; l'actif/l'actif/l'actif avec les politiques de conflit.
Capacité disque/réseau : Compter à partir de 'throughput × retence × replicas'.

8. 2 NATS

Cluster : beaucoup de nœuds, super-cluster (géo-distribution), leafnodes pour la périphérie/edge.
JetStream : placement des strimes par ensembles de nœuds (placement), réplication (R = 1.. 5).
WAN : des retards prévisibles, une fédération facile.

9) Sécurité

Kafka

TLS (mTLS), SASL: SCRAM, OAuthBearer.
ACL sur les tops/groupes/transactions.
Cryptage au repos (OS/disques) + stratégies réseau.

NATS

nkey/JWT identitaire, opérateur-compte, per-subject ACL.
mTLS entre les nœuds et les clients.
Isolation des locataires (comptes) + limites.

10) Observabilité et métriques opérationnelles

Kafka

Брокер: `BytesIn/Out`, `RequestQueue`, `UnderReplicatedPartitions`, GC/FS stats.
Topic/lot : 'logEndOffset', consumer lag (critique).
Producteur/consumer : retrai, 'batch. size`, `linger. ms`, `fetch. min. bytes ', erreurs.
Outils : JMX, Cruise Control (rééquilibrage), Schema Registry.

NATS/JetStream

Serveur : bou/msgs/sec, RTT, CPU/mem, détection de consommation lente.
JetStream: per stream/consumer — lag, redeliveries, acks, storage bytes.
Surveillance : endpoint intégré, nsc/adm-CLI, dashboards.

11) Performance et tuning

Kafka

Gros batchi et 'linger. ms'améliorent throughput et compriment p99.
La compression (lz4/zstd) permet d'économiser le réseau/disque.
num. partitions par nombre de consommateurs/noyaux, mais pas trop (overhead).
Disques : NVMe sont préférés, XFS/EXT4 avec 'noatime'.

NATS

Petits messages, beaucoup de connexions - la norme ; gardez les groupes queue « larges ».
JetStream: tune `max_ack_pending`, pull vs push, size of batches.
Backpressure: `FlowControl`, `IdleHeartbeat`, server-side limits.

12) Modèles d'intégration

Outbox/Inbox (à la fois à Kafka et à NATS).
SAGA : orchestration d'événements ; dedup par 'saga _ id + step'.
Change Data Capture (CDC): Debezium → Kafka; NATS est le modèle de « éditeur de déclencheurs/logs OBD ».
Stream processing: Kafka Streams/Flink/Spark; dans NATS - processeurs/fonctions tiers, JetStream consumers.
Dead Letter Queue (DLQ) et retry-policy (exponentielle backoff + jitter).

13) Exemples de configurations

13. 1 Kafka : Création d'un topic et producteur

bash kafka-topics. sh --create --topic orders \
--partitions 12 --replication-factor 3 \
--config cleanup. policy=delete \
--config retention. ms=604800000 # 7d

properties producer. properties bootstrap. servers=broker:9092 acks=all enable. idempotence=true batch. size=65536 linger. ms=10 compression. type=zstd

13. 2 Kafka Streams : traitement idempotent (croquis)

java builder. <String, Order>stream("orders")
.groupByKey()
.aggregate(/... /)
.toStream()
.to("orders-agg");

13. 3 NATS JetStream: stream + consumer (nats CLI)

bash nats stream add ORDERS --subjects "orders. " --retention limits \
--storage file --max-bytes 100GB --replicas 3 --discard old

nats consumer add ORDERS ORDERS-WORKERS --filter "orders. created" \
--deliver pull --ack explicit --max-deliver 6 --backoff "1s,5s,30s,2m"

13. 4 NATS Request-Reply (Go)

go nc, _:= nats. Connect("tls://nats:4222", nats. Secure(tlsConf))
sub, _:= nc. QueueSubscribe("calc. sum", "workers", func(m nats. Msg) {
//... process...
m. Respond([]byte("42"))
})

14) Sélection de Kafka vs NATS : une référence rapide

J'ai besoin d'une réplique, d'une rétention prolongée, d'une compaction, de processus lourds → Kafka.
Il faut un RPC rapide, un fan-out/fan-in avec microlatence, un fonctionnement facile, edge/IoT → NATS (Core).
Est nécessaire персистентность + le fan-hors-jeu, mais sans lourd "логовой" les quais → NATS JetStream.
Ordre strict par clé et transaction → Kafka.

15) Planification de la capacité (simplifiée)

Kafka

1. Passe : 'inbound _ MBps × RF × retention_days × 86400' disques →.
2. Lots : 'target _ concurrency' × stock 1. 5–2×.
3. Réseau : p99 + réplication + producteur de compression.

NATS/JetStream

1. Messages/s et taille moyenne → throughput.
2. Retention×replicas → storage.
3. Limites des consommateurs (ack-pending, redeliveries), CPU pour la sérialisation.

16) Fonctionnement sûr : chèque-feuille

• TLS/mTLS est activé, les secrets tournent.
• ACL/comptes/quotas (per-tenant).
• Idempotentialité sur les consumers, DLQ et retraits avec gitter.
• Surveillance de lag/throughput/erreurs ; alerte sur l'URP (Kafka), la tempête de redelivery (NATS).
• Capacity dashboards : lots, stockage, p99.
• Tests de défaillance de nœud/zone, jeux-jours, repli/backfill.
• Les clés de lot et de schéma (Schema Registry/JSON Schema) sont documentées.
• Les politiques de rétention/compaction/TTL sont harmonisées avec la conformité.
• Les versions des courtiers/clients sont régulièrement mises à jour ; la compatibilité du protocole wire a été vérifiée.

17) Anti-modèles

Clé chaude (tous les événements du même ID) → un seul flux « bouillant ». Chardonnez/tamponnez.
Retrai sans idempotence → effets de prise.
Messages énormes (MB-dizaines) → fragmentation/pause GC. Stockez payload dans l'objet, envoyez les liens.
Le mélange de RPC et de streaming dans Kafka → un cycle de vie/ordre complexe.
JetStream en tant que « DWH à long terme » → inapproprié ; conservez-le longtemps dans les cales objet/colonne.
Non DLQ → les messages « toxiques » tournent indéfiniment.
Rétention oubliée → disques pleins, arrêt du cluster.

18) FAQ

Q : Est-il possible de faire « exactly-once » à la fin de la pipline ?
R : Dans la pratique, oui efficace : Kafka (producteur idempotent + transactions) et sinks idempotent (clé, upsert). Dans NATS - par idempotence/dedup dans l'application.

Q : Que choisir pour un million de petits RPC/s ?
A : NATS Core : microlatence, request-reply, connexions légères et queue-groups.

Q : Besoin de compaction et de snapshots de fortune ?
A: Kafka с `cleanup. politique = compact ', clé = agrégat/ressource.

Q : Comment lutter contre la lagune ?
R : Augmenter le nombre de lots/workers, réduire le temps de traitement, batchi et prefetch, optimiser la désérialisation, renforcer verticalement les courtiers/disques.

Q : Multi-région et DR ?
A : Kafka - MirrorMaker 2/Cluster Linking, un atout-passer avec le RPO≈sekundy. NATS — supercluster/leafnodes; JetStream miroir/réplique par zone.

19) Résultats

Kafka et NATS ferment différents modes : Kafka - journaux d'événements durables, haute throughput, transaction et repli ; NATS est un bus ultra léger pour les faibles retards, RPC et simple fan-out, avec JetStream pour la persistance. Faites le choix de la sémantique de la livraison, de l'ordre et de la rétention, de la latence et des coûts d'exploitation. Concevez les clés/lots, la rétention, le DLQ et l'observabilité - et votre architecture d'événement sera prévisible, évolutive et fiable.