How to post messages to RabbitMQ from SQL Server?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
Posting messages to RabbitMQ from SQL Server is a common requirement when a database update must trigger work in another system. The key design decision is where message publishing should happen. You can do it inside SQL Server, but most production systems are safer when SQL only records events and a separate worker publishes to RabbitMQ.
Choose an Integration Pattern
There are three practical patterns:
- SQL CLR stored procedure that publishes directly to RabbitMQ.
- Service Broker plus an external activator process.
- Outbox table written in the same transaction, with a worker process that publishes.
The outbox pattern is usually the most reliable because SQL transactions remain local, network failures do not block writes, and retries are easy to manage. Direct publishing from SQL can work for small systems, but operational risk is higher.
Implement the Outbox Pattern in SQL Server
Create an outbox table that stores pending messages. Insert into business tables and outbox in one transaction.
This gives atomicity: if the order insert fails, the outbox row is not created. If commit succeeds, both are persisted.
Build a Publisher Worker in C#
Run a separate .NET worker that polls pending rows, publishes to RabbitMQ, and marks rows as published. This process can run as a Windows service, container, or scheduled job.
This loop is intentionally simple. In production, add cancellation tokens, structured logs, and metrics.
When Direct SQL Publishing Is Acceptable
If throughput is low and you control the environment, SQL CLR can be acceptable for internal tools. Service Broker plus external activator can also work if your team already uses Service Broker. The tradeoff is operational complexity. Database teams often prefer keeping SQL focused on persistence and moving broker communication into application services.
Common Pitfalls
- Publishing inside a trigger and slowing down writes when RabbitMQ is slow.
- No idempotency on consumers, causing duplicate side effects during retries.
- Marking rows as published before broker confirmation.
- Unlimited retries with no dead letter handling strategy.
- Building JSON payloads by string concatenation without validating payload shape.
Summary
- Use an outbox table when you need reliability and clear failure handling.
- Keep SQL transactions local and move broker publishing to a worker service.
- Publish with durable messages and track retries plus last error.
- Mark events as published only after successful broker publish.
- Add consumer idempotency and dead letter policies for end to end safety.
Related reading
- How to prevent duplicate SQS Messages?
- How to Process a kafka KStream and write to database directly instead of sending it another topic
- how to process data in chunks/batches with kafka streams?
- How to process logs from distributed log broker (Eg Kafka) exactly after 1 week?
- How to prepend a string to a column value in MySQL?
- How to prevent a DynamoDB item being overwritten if an entry already exists
- How to produce a json object message into kafka topic using java(spring)?
- How to produce Kafka Events in Django the right way

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.