Product / Signal Relay
Signal Relay
A bounded authenticated mailbox for leaving a signal that another application can retrieve and acknowledge.
Current Tier 1 foundationLeave a signal for another application
Signal Relay separates sender availability from receiver availability. Application A creates a small authenticated signal for Application B. The receiver later reads pending signals through its own authenticated polling flow and ACKs after its business action succeeds.
Current Tier 1 flow
The implemented contract supports create, pending read and explicit ACK. Creation uses a stable idempotency key, while each HTTP attempt receives fresh timestamp, nonce, request ID and signature fields. Pending reads do not remove a signal; ACK changes the recorded state.
Advantages
- the receiver does not need to expose an inbound endpoint;
- small coordination messages can wait while the receiver is offline;
- authentication and tenant/application scope are explicit;
- retry-safe creation reduces duplicate logical signals after an unknown timeout.
Limitations and delivery semantics
This is not a streaming system, Kafka replacement, bulk transport or exactly-once execution engine. A receiver must make its business action safe to repeat. The current implementation has no lease endpoint; do not describe a lease or claim a stronger delivery guarantee than the pending-read-until-ACK contract proves.
When another product is better
Use Heartbeat Monitor when the only question is whether an application checked in. Use Polling Relay language when the important receiver constraint is controlled retrieval without inbound access.