Sub Delivery
Sub delivery sends queued messages from a topic to a target app or worker. To set up sub delivery, you define a subscription, pick a push or pull mode, and grant a role to the worker. Many teams start by giving the worker broad database and queue permissions so jobs do not fail. Over time, those wide roles let any bad message trigger unsafe reads or writes across production data. How sub delivery works in modern message queues In a publish and subscribe system, senders push events to a centra
Delivery: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Sub delivery sends queued messages from a topic to a target app or worker. To set up sub delivery, you define a subscription, pick a push or pull mode, and grant a role to the worker. Many teams start by giving the worker broad database and queue permissions so jobs do not fail. Over time, those wide roles let any bad message trigger unsafe reads or writes across production data.
How sub delivery works in modern message queues
In a publish and subscribe system, senders push events to a central topic. The topic does not send data straight to the worker app. Instead, a subscription sits between the topic and the consumer to manage message flow. This sub delivery step tracks which messages the worker has read and processed.
Teams usually pick between two main ways to move these messages. In pull mode, the worker app asks the queue for new messages when it has free capacity. In push mode, the queue sends the message straight to a webhook URL on the worker. Both modes wait for the worker to send back a success signal before they delete the message.
If the worker crashes or times out, the queue holds the message and tries again later. After too many failed tries, the system moves the stuck message to a dead-letter queue. An engineer then logs in to inspect the payload and fix the broken job.
Why native queue roles leave a security gap
Native queue permissions do a good job of deciding which service account can read from a subscription. You can bind a role so only one worker app can pull messages or send back success signals. This stops random apps from reading events they should not see.
The gap appears after the worker receives the message and starts to run business logic. To finish its job, the worker often has to query a database or run a shell command. Native queue roles only check who logs in to the topic, not what the worker does next.
Delivery: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Even worse, engineers often need direct access to the queue and database to fix dead-letter messages. When a human logs in with a shared admin role to replay a job, every query runs with full trust. Native roles cannot check individual SQL statements in flight or rewrite sensitive fields like emails, phone numbers, or card numbers.
How to tighten worker and human access during triage
Start by splitting the role that reads the queue from the role that writes to the database. Give each worker a narrow role that only touches the tables it needs for that one task. Set a clear retry limit on every subscription so bad messages move to a dead-letter queue fast.
Next, remove standing admin keys from developer laptops and shared jump servers. When a team member needs to inspect a failed sub delivery payload, require an approval step for write actions. Masking rules that rewrite card numbers and national IDs in query results also help keep raw data off local screens during triage.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between push and pull sub delivery?
In pull mode, your worker app asks the queue for messages at its own pace. In push mode, the queue sends each message straight to an HTTP endpoint on your app as soon as it arrives.
How do you stop a poison message from blocking sub delivery?
Set a maximum retry count on the subscription and attach a dead-letter topic. When a message fails too many times, the queue moves it aside so healthy messages can keep flowing.
Why do dead-letter queues create a data risk?
Failed messages often hold raw user data like emails, phone numbers, or card numbers inside the payload. When engineers log in with broad roles to inspect and replay those messages, they can expose sensitive fields or run unsafe queries.