English for NATS Messaging Developers

NATS has grown in popularity as a lightweight, high-performance messaging system for distributed systems and microservices. If you work with NATS on an international team, you’ll need clear English to describe subjects, delivery guarantees, and stream persistence. This guide covers the core vocabulary for NATS messaging developers.

Key Vocabulary

Subject — the string used to address a message in NATS, similar to a topic, which subscribers match against to receive messages. “We publish order events to the subject orders.created, and our billing service subscribes to orders.> to catch all order-related events.”

Publish-subscribe — the core NATS messaging pattern where a publisher sends a message to a subject, and any number of subscribers can receive it. “With publish-subscribe, adding a new service that needs order events doesn’t require changing the publisher at all — it just subscribes.”

JetStream — the persistence layer built on top of core NATS, adding message storage, replay, and at-least-once delivery guarantees. “Core NATS is fire-and-forget, so we use JetStream whenever we need messages to survive a subscriber being temporarily offline.”

Stream — a JetStream construct that stores messages published to one or more subjects, retaining them according to a configured policy. “We created a stream that captures all subjects under orders.* and retains messages for thirty days.”

Consumer — an entity that reads messages from a JetStream stream, tracking its own position so it can resume after a restart. “Each service runs its own durable consumer on the orders stream, so restarting one service doesn’t affect the others’ progress.”

Acknowledgement (ack) — a signal a consumer sends back to JetStream confirming it successfully processed a message, allowing at-least-once delivery. “If a consumer crashes before acknowledging a message, JetStream redelivers it once the consumer reconnects.”

Wildcard subscription — a subscription using * or > to match multiple subjects at once, such as one level or all remaining levels. “We subscribe to orders.*.updated to catch update events for any order type in a single subscription.”

Queue group — a set of subscribers sharing a name, where NATS delivers each message to only one member of the group, enabling load balancing. “We put all instances of our worker service in the same queue group, so each incoming job is handled by exactly one instance.”

Discussing Delivery Guarantees

• “Core NATS gives us at-most-once delivery — fine for ephemeral telemetry, but not for anything we can’t afford to lose.”
• “We moved billing events onto JetStream because we needed at-least-once delivery with replay if a consumer falls behind.”
• “Our consumer explicitly acknowledges messages only after the database write succeeds, to avoid losing data on a mid-process crash.”

Talking About Scaling and Load Balancing

• “Using a queue group let us scale our worker service horizontally without any messages being processed twice under normal operation.”
• “We separated read-heavy consumers from write-heavy ones by subject, so a slow consumer on one subject doesn’t back up unrelated traffic.”
• “Wildcard subscriptions kept our subscriber code simple — we didn’t need to hardcode every possible order type.”

Professional Tips

1. Be precise about delivery guarantees in documentation. “At-least-once” and “at-most-once” sound similar but have very different implications for data integrity.
2. Explain queue groups in terms of load distribution, not just terminology. “Only one instance handles each message” is clearer than the raw term to non-NATS-familiar reviewers.
3. Design consumers to be idempotent. At-least-once delivery means duplicate messages are expected, not exceptional.

Practice Exercise

1. Explain to a teammate, in 3-4 sentences, the difference between core NATS and JetStream.
2. Write a short explanation (4-5 sentences) of why your service uses a queue group instead of individual subscriptions.
3. Describe, in plain English, how at-least-once delivery affected the design of your message handler, and why idempotency mattered.