Overview#
High-volume data ingestion events, alert deliveries, and cross-component notifications all arrive at different rates and with different urgency. The Message Queue domain absorbs that load reliably: priority queuing ensures critical messages move first, retry policies handle transient failures, and a dead letter queue captures anything that cannot be delivered so nothing is silently dropped.
Key Features#
- Priority-based message queuing for ordered delivery
- Configurable retry policies with backoff strategies
- Delivery tracking with attempt history
- Dead letter queue for failed message handling
- Batch processing for high-throughput scenarios
- Message status monitoring and statistics
- Multi-tenant message isolation
Use Cases#
Relevant sectors include critical infrastructure, financial crime platforms, and law enforcement command systems.
- Delivering asynchronous notifications across platform components reliably
- Processing high-volume data ingestion messages with priority ordering
- Handling failed message delivery with dead letter queue review
- Monitoring message queue health and throughput for operational visibility
Integration#
The Message Queue domain integrates with Notification for delivery, Ingestion for data processing, Alert for event-driven messaging, and Monitor for queue health tracking.
Open Standards#
- GraphQL (June 2018 specification): the entire message queue API surface, including enqueue, retry, prioritisation, dead-letter retrieval, and queue statistics, is exposed as a typed GraphQL schema with queries and mutations.
- JSON (RFC 8259): all message payloads, webhook bodies, delivery-attempt metadata, and queue statistics are encoded as JSON; the GraphQL schema uses a scalar JSON type throughout.
- HTTP Semantics (RFC 9110): outbound webhook delivery uses HTTPS POST with
Content-Type: application/json, follows redirect status codes (301, 302, 303, 307, 308) per the specification, and treats 2xx response codes as successful delivery. - URI Syntax (RFC 3986): webhook destination URLs are validated against RFC 3986 structure, credentials in URLs are rejected, and IPv6 literal addresses in authority components are bracketed as required by section 3.2.2.
- Date and Time (ISO 8601 / RFC 3339): all message timestamps, creation, send, failure, archive, and scheduled delivery, are stored and serialised as UTC ISO 8601 strings.
- JSON Web Token (RFC 7519): RS256-signed JWTs are verified via JWKS on every queue query and mutation to establish caller identity and tenant context.
- OAuth 2.0 (RFC 6749): bearer-token authorisation protects all queue endpoints; tokens are issued and validated through the platform's centralised auth service.
Last Reviewed: 2026-02-05 Last Updated: 2026-04-14