What it does
Publish with a plain HTTP call
One event, a batch, or a stream of lines: the ingester answers one result per event, once the broker took it, with its position. Nothing is lost in silence.
JSON lines, server-sent events, websockets
Stream events to any HTTP client. Groups, at-least-once delivery, replay from the beginning, a date or an offset, and server-sent events that resume where the client stopped.
Every event is a CloudEvent
With the protocol binding of each broker: what the gateway publishes, any CloudEvents SDK reads, and what another producer published is read as an event too.
Not the lowest common denominator
Kafka keys and offsets, RabbitMQ confirms, topologies and streams, Pulsar subscriptions, Redis streams groups, MQTT 5 shared subscriptions, Artemis addresses, selectors and message groups.
Events pushed to HTTP endpoints
Signed, retried with backoff, dead-lettered when they cannot go, delivered by one node of the cluster at a time.
TLS and authentication everywhere
Mutual TLS with the certificates of the Otoroshi store, SASL, tokens, secrets from vaults. And the route decides what its callers may ask: nothing but shaping their own response, by default.
Exporter, workflows, request reply
Send Otoroshi events to any broker, publish and consume from workflows, or answer an HTTP call with the event that replies to it.
Connections that take care of themselves
Connected in the background, checked, rebuilt, switched to new settings without a dropped request. Their state, their traffic and the lag of their groups in the admin API, the backoffice, and the metrics.
Two routes, and your broker is on the web
A connection to the broker, an ingester route, a consumer route. The quickstart takes five minutes with Docker.
# publish
curl -X POST 'http://events.oto.tools:8080/' \
-H 'Content-Type: application/json' -d '{"order": 42}'
# consume, as server-sent events
curl -N 'http://events-stream.oto.tools:8080/'