Nats Pubsub
You set up nats pubsub by connecting apps to a shared server cluster. Apps then send and read messages using named text strings called subjects. Many engineering teams start with one shared account for all services. They often allow wildcard rules so new apps can talk right away. When roles are too broad, any app or user can read every message. A developer testing a fix might also send bad data to live subjects. How nats pubsub routes messages and checks rules In a nats pubsub system, publish
NATS Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up nats pubsub by connecting apps to a shared server cluster. Apps then send and read messages using named text strings called subjects. Many engineering teams start with one shared account for all services. They often allow wildcard rules so new apps can talk right away. When roles are too broad, any app or user can read every message. A developer testing a fix might also send bad data to live subjects.
How nats pubsub routes messages and checks rules
In a nats pubsub system, publishers send data to a subject string. Subscribers listen to that exact subject string and get the message right away. The server does not hold messages in memory by default. If no app listens when a message arrives, the server drops it. Teams add a persistence engine when they need to save messages on disk. This engine lets apps read old messages or replay a full stream later.
You can group subscribers together to share a heavy work load. When you set up a queue group, the server picks one listener per message. This setup spreads the work across many app instances without extra code. You can also use tokens and wildcards to match many subjects at once. A single token wildcard matches one word in the subject hierarchy. A full wildcard matches all words that come after a chosen prefix.
To lock down traffic, admins create separate accounts on the server. Each account acts as an isolated space for a specific team or service. Inside an account, you assign publish and subscribe rules to each user key. These rules list the exact subjects a user or app can touch. Accounts can also export and import subjects to share data across teams.
What native subject rules solve and what they miss
Native account and subject rules decide which app can join the server. They also control which subject names a client can read or write. This setup stops an unknown app from reading messages in another team space. It works well for stable services that run the same code every day. You can map out service keys and subject lists ahead of time.
Still, static subject rules struggle when humans need to check or fix live streams. Engineers often log in with shared keys to inspect broken message flows. Once they log in, the server checks the subject name, not the payload. Native rules do not inspect what individual commands or payloads do in flight. A user with publish rights can send a bad message that breaks consumers.
NATS Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static rules also do not rewrite sensitive data inside a message payload. If a stream carries emails, phone numbers, or card numbers, readers get raw text. Sharing one admin key across a team also ruins your audit logs. You can see that an account sent a message, but not which person did it. Teams need a way to tie every action to a real user identity.
How to manage human sessions on live message streams
Start by separating machine keys from human logins across all your clusters. Apps should keep using strict, narrow subject rules for their daily work. Engineers should never copy app keys to their laptops to debug an issue. Instead, map human sessions to your central identity provider so every person logs in.
Next, review what data flows through your most active subjects. When streams carry emails, phone numbers, or national IDs, apply data masking rules. Masking rewrites matched fields in results before they reach the reader screen. You should also require quick peer approval before someone publishes to a production subject. This step stops typos from crashing downstream apps during a live incident.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How does nats pubsub handle slow consumers?
The core server buffers messages in memory for each connected client. If a reader falls too far behind, the server drops messages and closes the link. Teams enable the persistence engine when slow readers must not lose any data.
Can nats pubsub save messages for apps that are offline?
Standard pubsub only sends data to apps that are online right now. To save messages for offline apps, you must turn on the built-in persistence engine. That engine stores streams on disk or in memory until the reader returns.
How should teams organize subject names across many services?
Use short words separated by dots to build a clear tree structure. Start with the domain or team name, then add the app and event type. Clear prefixes make it easy to write tight publish and subscribe rules later.