When HTTP Delivery Needs More Than Delivery
Solace REST Delivery Points (RDPs) provide a straightforward broker-native solution for a common event-driven integration pattern: take a message from a queue and deliver it to an HTTP endpoint, without requiring a separate delivery application in the middle.
But where should the boundary sit between broker-native delivery and application-level delivery logic?
Consider a downstream service that starts failing repeatedly. Should retries progressively back off? Should calls temporarily stop when the service is unavailable? What if the payload needs to be transformed before delivery, or the HTTP response needs to influence what happens to the original message?
At that point, the requirement starts moving beyond HTTP delivery into resilience, transformation, response handling, and observability.
RDP Bridge explores that boundary: where broker-native HTTP delivery ends and application-level delivery logic begins.
What Solace RDP Already Does Well
Solace RDP already provides a capable broker-native solution for delivering queued messages to HTTP endpoints. It requires no additional application runtime and keeps delivery within the Solace platform.
Out of the box, RDP provides capabilities such as multiple authentication schemes, broker HA/DR, substitution expressions for request targets and headers, retry behavior, and configurable rejection codes for handling permanent HTTP failures.
For integrations where the requirement is essentially queue → HTTP endpoint, this keeps the architecture simple and operationally efficient.
RDP Bridge is therefore not intended to replace RDP. The interesting case begins when the HTTP delivery itself requires behavior that belongs at the application layer.
Where the Boundary Sits
The boundary becomes visible when delivery requires decisions beyond whether an HTTP request succeeded or failed. A downstream service may need progressive retry backoff, a circuit breaker to temporarily stop calls after repeated failures, payload transformation, more flexible response-driven handling, or per-message delivery visibility for troubleshooting.
For these scenarios, RDP Bridge takes a different delivery path. Instead of RDP delivering the message to the HTTP endpoint, the bridge consumes the message directly from the Solace queue and takes responsibility for the HTTP delivery and its application-level policies.
Solace still provides the underlying messaging guarantees, including queueing, guaranteed delivery, redelivery, and dead-message handling, while the bridge handles the HTTP delivery logic.
That division of responsibilities is the foundation of RDP Bridge.
What We Built: RDP Bridge
RDP Bridge is an open-source Ballerina service that consumes messages directly from a Solace queue using CLIENT_ACK mode and delivers them to configured HTTP targets.
Tech Venturas is an active Ballerina user, featured in the “Who uses Ballerina?” section of the official Ballerina website. RDP Bridge builds on our practical use of Ballerina for enterprise integration.
The bridge adds the application-level delivery capabilities discussed above: configurable retry with progressive backoff, configurable circuit breaking, response-driven message handling, payload transformation, structured logging, and Prometheus metrics.
The delivery outcome determines what happens to the original Solace message:
| HTTP outcome | Bridge action |
|---|---|
| 2xx | Acknowledge the message. |
| 4xx | Treat as a permanent failure: negatively acknowledge with requeue=false, routing toward dead-message handling according to broker configuration. |
| 5xx / timeout | Retry with backoff, then allow broker redelivery if retries are exhausted. |
| Circuit open | Avoid calling the unhealthy target and return the message for later redelivery. |
Configuration, including routing, authentication, retry policy, circuit-breaker thresholds, and payload transformation, is externalized through Ballerina configuration, allowing delivery behavior to change without rebuilding the service.
For a detailed view of the message delivery flow, including transformation, retries, circuit-breaker behavior, acknowledgements, and redelivery, see the sequence diagram in the GitHub repository.
The implementation and runnable examples are available in the open-source RDP Bridge repository.
RDP vs. RDP Bridge in Practice
RDP Bridge is not intended to make RDP obsolete. The two approaches fit different delivery requirements.
| Capability | Solace RDP | RDP Bridge |
|---|---|---|
| HTTP delivery | Broker-native | Application-managed |
| Retry / resilience | Broker-managed delivery and redelivery; configurable connection retry delay and queue redelivery policies | Application-managed retries with progressive backoff and circuit breaking |
| Circuit breaker | Not provided | Configurable, with open and half-open states |
| Response handling | HTTP status and configurable rejection codes | Application-level response classification |
| Payload transformation | Body delivered unchanged | Config-driven transformation and enrichment |
| Observability | Broker-level | Structured per-message logs and Prometheus metrics |
| Operational footprint | No additional service | Additional application runtime |
The project includes runnable samples covering different delivery scenarios. The resilient-delivery sample runs native RDP and RDP Bridge side by side against the same failing HTTP target, making the differences in retry and circuit-breaker behavior directly observable.
Open Source, Limitations & What’s Next
RDP Bridge is open source under the Apache 2.0 license, with the implementation, configuration examples, and runnable scenarios available in the project repository.
The project is still evolving. Production-scale performance, horizontal scaling, hardened secrets and TLS configuration, and broader automated integration testing remain areas for further engineering and validation.
As an official Solace partner, Tech Venturas continues to explore practical engineering patterns for real-world Solace integration scenarios.
Acknowledgements
This initiative grew out of a technical discussion with Jochen Traunecker, whose insights provided the initial catalyst for exploring the boundary between broker-native REST delivery and application-level delivery logic. We thank Jochen for helping inspire this work.
The RDP Bridge implementation was developed by Isuru Gunawardana at Tech Venturas as part of our ongoing engineering work with Solace technologies. We welcome technical feedback, contributions and further discussion from the wider developer community.