NATS developers build and maintain the high-performance, cloud-native messaging infrastructure that connects distributed microservices through subject-based pub/sub, request-reply, and queue subscriber patterns — publishing messages to hierarchical subjects, configuring consumer groups that load-balance across subscriber instances, and operating JetStream persistence that adds at-least-once and exactly-once delivery guarantees, durable consumer checkpointing, and key-value and object store primitives to NATS's core at-most-once messaging model. At remote-first technology companies, they serve as the platform and backend engineers who replace heavyweight message brokers — the Kafka clusters and RabbitMQ exchanges that require dedicated operations teams to size, tune, and manage — with NATS's single binary that embeds messaging, streaming, key-value, and service mesh capabilities while consuming a fraction of the infrastructure footprint.
What NATS developers do
NATS developers connect clients — initializing nats.connect('nats://localhost:4222') in Go or const nc = await connect({ servers: 'nats://localhost:4222' }) in Node.js with reconnect options (maxReconnectAttempts, reconnectTimeWait) and TLS configuration for secure cluster connections; publish and subscribe — calling nc.Publish('orders.created', data) for fire-and-forget fan-out delivery to all active subscribers on the subject, and nc.Subscribe('orders.created', handler) with subject wildcards (orders.* for single token, orders.> for multi-token) to receive matching messages; implement request-reply — using nc.Request('auth.validate', payload, timeout) for synchronous RPC patterns where the server subscribes to the subject and replies using the message's reply field, enabling microservice call patterns over NATS without HTTP; implement queue groups — subscribing with nc.QueueSubscribe('orders.process', 'workers', handler) so that multiple instances sharing a queue group name receive load-balanced message delivery rather than fan-out, implementing horizontal scaling of message consumers; configure JetStream — creating streams with js.AddStream({ name: 'ORDERS', subjects: ['orders.>'], storage: StorageType.File, maxAge: nanos(24 * 60 * 60) }) to persist messages beyond subscriber availability, with retention policies (LimitsPolicy, WorkQueuePolicy, InterestPolicy) controlling message lifecycle; create consumers — using js.AddConsumer('ORDERS', { durable_name: 'order-processor', ack_policy: AckPolicy.Explicit, deliver_policy: DeliverPolicy.All, filter_subject: 'orders.created' }) for durable pull consumers that checkpoint delivery position and enable exactly-once processing with MsgID deduplication; implement push consumers — creating push-bound consumers with deliver_subject for low-latency streaming delivery to specific subjects, with ack_wait and max_deliver controlling retry behavior for failed acknowledgements; use key-value store — creating KV buckets with js.CreateKeyValue({ bucket: 'CONFIG', history: 5, ttl: nanos(3600) }) for distributed configuration and presence tracking, and watching with kv.Watch('config.*') for real-time change notifications; use object store — storing binary blobs with js.CreateObjectStore({ bucket: 'ASSETS', storage: StorageType.File }) for file distribution across services; configure NATS clustering — running nats-server with cluster routes and defining leaf node connections for hub-and-spoke topologies that span multiple clouds or data centers; implement NATS security — configuring operator/account/user NKey-based authentication with decentralized JWT authorization, or username/password credentials, with account isolation controlling which subjects cross account boundaries; and use NATS CLI — operating nats pub, nats sub, nats req, nats stream, nats consumer, and nats kv for operational inspection and debugging.
Key skills for NATS developers
- Core messaging: pub/sub; subject hierarchy; wildcards (*//>); request-reply; queue groups
- JetStream: streams; consumers; AckPolicy; DeliverPolicy; RetentionPolicy; StorageType
- Consumers: durable; ephemeral; pull consumer; push consumer; filter_subject; ack_wait
- Exactly-once: MsgID deduplication; double-ack; idempotent consumers
- KV store: CreateKeyValue; Put/Get/Delete; Watch; history; TTL; bucket config
- Object store: CreateObjectStore; Put/Get; chunks; metadata
- Clustering: cluster routes; leaf nodes; gateway connections; hub-and-spoke
- Security: NKeys; operator/account/user JWT; TLS; credentials file; permissions
- SDKs: nats.go; nats.deno/nats.ws (Deno/Node.js); nats.py; nats.net; nats.java
- CLI: nats pub/sub/req; nats stream/consumer/kv; nats server check
Salary expectations for remote NATS developers
Remote NATS developers earn $108,000–$172,000 total compensation. Base salaries range from $90,000–$142,000, with equity at technology companies where inter-service messaging reliability, event-driven architecture throughput, and the operational simplicity of a single messaging binary replacing multi-component broker infrastructure directly reduce platform complexity and improve delivery performance. NATS developers with JetStream stream topology design for high-throughput event pipelines requiring durable delivery and consumer checkpoint recovery, NATS clustering with leaf node topologies spanning multi-cloud and edge deployments, NKey-based security model implementation for zero-trust microservice authentication, and demonstrated infrastructure consolidation where NATS replaced Kafka or RabbitMQ with equivalent delivery guarantees at reduced operational overhead command the strongest premiums. Those with NATS combined with deep Kubernetes and service mesh architecture expertise earn toward the top of the range.
Career progression for NATS developers
The path from NATS developer leads to senior platform engineer (broader scope across the full event-driven infrastructure including messaging, streaming, and service discovery), distributed systems architect (designing the inter-service communication model across microservice architectures where NATS serves as the nervous system), or infrastructure engineer (expanding to the broader cloud-native networking and messaging ecosystem). Some NATS developers specialize into edge computing, using NATS's leaf node topology to connect IoT devices and edge compute nodes to central cloud infrastructure through a single messaging plane that handles connectivity, configuration distribution, and telemetry collection. Others transition into event-driven architecture consulting, applying NATS's subject hierarchy and consumer group patterns to replace synchronous HTTP-heavy microservice graphs with asynchronous event flows. NATS developers who contribute to the ecosystem — building SDKs for emerging languages, developing NATS connectors for data pipeline tools, or writing operator tooling for NATS cluster management — contribute to one of the fastest-growing CNCF projects.
Remote work considerations for NATS developers
Building NATS-based messaging infrastructure for distributed engineering teams requires subject hierarchy standards, JetStream consumer ownership conventions, and security model governance that prevent distributed engineers from creating flat subject namespaces where every service publishes to top-level subjects that create unintended subscription fan-out, deploying queue subscribers without durable consumers in JetStream contexts where message loss is unacceptable, or operating without account isolation so that a noisy subject from one team affects delivery latency for another. NATS developers at remote companies establish the subject naming convention — documenting the <domain>.<entity>.<event> pattern (e.g., orders.payment.completed, auth.user.created) and team-level subject prefixes that scope ownership — because distributed engineers who publish to overlapping or ambiguous subject hierarchies create wildcard subscription collisions that cause services to receive messages they didn't intend to consume; enforce the JetStream vs core NATS decision — documenting that core NATS pub/sub (no JetStream) is appropriate only for fire-and-forget telemetry or ephemeral cache invalidation where message loss is acceptable, and that any workflow requiring delivery guarantees must use a JetStream durable consumer — because distributed engineers who use core NATS pub/sub for order events or payment notifications lose messages when consumers are offline; establish consumer ownership — requiring that each durable consumer be owned by a single service with a defined ack_policy and max_deliver — because shared durable consumers create split delivery where competing services each receive some fraction of the message stream; and document the reconnect configuration requirement — requiring that all NATS clients configure maxReconnectAttempts: -1 (infinite) and reconnectTimeWait — because clients with default reconnect limits silently stop receiving messages after a cluster failover.
Top industries hiring remote NATS developers
- Cloud-native platform engineering organizations where NATS's single binary embeds messaging, streaming, key-value, and object store capabilities that would otherwise require Kafka, Redis, etcd, and a file storage service as separate operational concerns
- IoT and edge computing companies where NATS's leaf node topology enables millions of edge devices to connect through a hierarchical messaging plane that routes telemetry to cloud processing and pushes configuration updates to devices without dedicated per-device connections
- Financial services and trading organizations where NATS's microsecond latency — orders of magnitude faster than Kafka for sub-millisecond message delivery — satisfies the low-latency inter-service communication requirements of market data distribution and order routing systems
- Gaming and real-time application companies where NATS's request-reply and queue subscriber patterns support matchmaking, presence, and game state synchronization at millions of concurrent connections across geographically distributed server clusters
- Multi-cloud and hybrid infrastructure organizations where NATS clustering with gateway connections provides a unified messaging plane that spans AWS, GCP, Azure, and on-premises data centers through a single subject namespace without cloud-vendor-specific messaging APIs
Interview preparation for NATS developer roles
Expect messaging model questions: explain the difference between NATS core pub/sub and JetStream — when would you use each, and what does a message loss risk scenario look like with core NATS. Queue group questions ask how you'd horizontally scale a message consumer so that ten worker instances each process a subset of messages without duplicates — what QueueSubscribe does and how it differs from independent subscriptions. JetStream questions ask how you'd configure a stream and durable consumer that processes order events with at-least-once delivery, retrying failed messages up to three times before moving them to a dead-letter subject — what ack_policy, max_deliver, and nack look like. KV store questions ask how you'd implement distributed configuration that pushes updates to all service instances within seconds — what Watch on a KV bucket looks like. Security questions ask how you'd isolate two teams' subjects so that team A's subscribers cannot accidentally receive team B's messages — what NATS accounts and subject permissions look like. Exactly-once questions ask how NATS JetStream achieves exactly-once delivery and what the publisher and consumer both need to do — what MsgID deduplication and double-ack look like. Be prepared to compare NATS with Kafka — the operational complexity, latency, and persistence trade-offs.
Tools and technologies for NATS developers
Core: NATS Server 2.x; nats-server binary; JetStream; NATS CLI (nats). SDKs: nats.go (Go); nats.deno + nats.ws (Node.js/Deno); nats.py (Python); nats.net (C#); nats.java (Java); nats.c (C). Core messaging: subject hierarchy; wildcards (* and >); pub/sub; request-reply; queue groups; drain; flush. JetStream streams: AddStream; stream config (subjects, storage, retention, maxAge, maxMsgs, replicas); stream info; purge; delete. JetStream consumers: AddConsumer; durable; ephemeral; AckPolicy (Explicit/All/None); DeliverPolicy (All/New/ByStartSequence/ByStartTime); FilterSubject; AckWait; MaxDeliver; pull consumer Fetch; push consumer deliver_subject. Exactly-once: MsgID; PublishOptions; double-ack pattern; deduplication window. KV store: CreateKeyValue; Put/Get/Delete/Purge; Watch; KeyValueEntry; bucket config (history, TTL, replicas). Object store: CreateObjectStore; Put/Get/Delete; chunks; metadata; object info. Clustering: cluster routes; leaf nodes; gateways; hub-and-spoke topology; JetStream clustering (R1/R3). Security: NKeys; operator/account/user JWT; TLS (mutual TLS); credentials file (.creds); subject permissions; deny rules; import/export. Monitoring: /varz; /connz; /routez; /jsz; /healthz; nats server check; Prometheus NATS Exporter. Alternatives: Kafka (high-throughput partitioned log, stronger ordering guarantees); RabbitMQ (AMQP, rich routing); Redis Pub/Sub (ephemeral, no persistence); Pulsar (multi-tenancy, tiered storage); MQTT (IoT protocol, lightweight).
Global remote opportunities for NATS developers
NATS developer expertise is in growing demand globally, with NATS's emergence as a CNCF incubating project and adoption by organizations including Synadia (the company behind NATS), PayPal, Mastercard, and Apcera for high-performance distributed messaging — creating consistent demand for engineers who understand both NATS's messaging model and the JetStream persistence layer that extends it to production event streaming workloads. US-based NATS developers are in demand at cloud-native platform teams replacing heavier messaging infrastructure, IoT companies building edge-to-cloud data pipelines, and financial services organizations requiring low-latency inter-service messaging. EMEA-based NATS developers are well-positioned given NATS's growing European adoption in cloud infrastructure and telecommunications — European telecommunications companies and cloud providers have adopted NATS for network function messaging and edge computing. NATS's continued development — JetStream reaching production maturity, the NATS security model with operators and accounts, and NATS's role in Synadia Cloud as a managed global messaging fabric — ensures sustained demand as event-driven microservice architectures require messaging infrastructure that scales from embedded single-node deployments to global multi-cluster fabrics.
Frequently asked questions
What is the difference between NATS core messaging and JetStream, and when should you use each? NATS core messaging is a fire-and-forget pub/sub system — when a publisher sends a message to a subject, all currently-connected subscribers receive it, and if no subscriber is connected or a subscriber is slow, messages are dropped. This is at-most-once delivery: fast (sub-millisecond), zero persistence overhead, appropriate for ephemeral data like live telemetry, cache invalidation broadcasts, and request-reply service calls where the caller handles retries. JetStream adds a persistence layer on top of NATS core: messages published to a JetStream stream are durably stored (in-memory or file-backed), consumers track their position in the stream and receive unacknowledged messages on retry, and the stream retains messages for configurable periods or counts regardless of subscriber availability. JetStream supports at-least-once delivery (explicit ack required, max_deliver controls retries) and exactly-once delivery (MsgID deduplication + double-ack pattern). Use JetStream when: subscriber availability is not guaranteed (services restart), message loss is unacceptable (orders, payments, state changes), you need replay from a specific position (new service instances catching up), or you need audit/compliance retention. Use core NATS when: the data is ephemeral (live price ticks, heartbeats), the sender can generate a fresh message rather than replay, and the overhead of JetStream persistence is not justified.
How do NATS queue groups and JetStream consumer groups differ? NATS core queue groups: multiple subscribers call QueueSubscribe with the same queue group name; NATS server load-balances incoming messages across the group so each message goes to exactly one subscriber; if all subscribers disconnect, queued messages are dropped (no persistence). JetStream durable consumers: a durable consumer with a filter_subject tracks delivery position in a persistent stream; multiple service instances pull from the same durable consumer using Fetch (pull consumers) — the server delivers each message to exactly one instance, which must explicitly acknowledge it; unacknowledged messages are redelivered after ack_wait expires; if all instances disconnect, messages accumulate in the stream and are delivered when instances reconnect. The key difference: queue groups are ephemeral (messages are lost if no subscriber is connected), JetStream durable consumers are persistent (messages survive subscriber downtime). For reliable work queues, use JetStream with a WorkQueuePolicy stream and an explicit-ack durable consumer — core NATS queue groups are appropriate only for stateless load balancing of requests where loss is acceptable.
How does NATS JetStream achieve exactly-once delivery? Exactly-once in JetStream requires cooperation from both publisher and consumer. Publisher side: the publisher sets a unique MsgID in the publish options (nc.Publish(subject, data, nats.MsgId(uniqueId))); NATS Server deduplicates within the stream's DuplicateWindow (default 2 minutes) — if the same MsgID is published twice within the window, the second is silently dropped, protecting against publisher retries from producing duplicate messages. Consumer side: exactly-once requires the double-ack pattern — the consumer receives the message, processes it, then calls msg.AckSync() (a synchronous ack that waits for the server to confirm receipt of the acknowledgement); after receiving AckSync, the consumer checks the server's acknowledgement confirmation before committing the side effect locally. Standard msg.Ack() (fire-and-forget) gives at-least-once: if the ack is lost in transit, the server redelivers the message. Double-ack (AckSync) gives exactly-once: the consumer doesn't proceed until it knows the server recorded the ack. Combined with MsgID deduplication on the publisher side, the full pattern achieves end-to-end exactly-once for the duration of the deduplication window.