
The Business Case for TYO MQ
Choosing messaging infrastructure is rarely about messaging. It's about how fast your team can ship the next feature, what your monthly bill looks like, where your data lives, and whether the choice you make this year becomes the migration you dread in three. Here is TYO MQ's case, in those terms.
Ship in days what used to take a quarter
The conventional path to "real-time and reliable" is assembling a stack: a broker for durability, a WebSocket layer for the browser, a retry service, a dead-letter store, an admin UI, and the glue code between them — each with its own failure modes, upgrade cycles, and expertise requirements.
TYO MQ collapses that stack into one dependency. Durable queues, ACK and retry, dead-letter handling, topic routing, worker pools, browser delivery, multi-tenant auth, and Prometheus metrics ship in the box, switched on by options rather than built by hand. The samples repository makes the point concretely: a complete webhook delivery system — the kind teams spend weeks on — is about a dozen lines of handler code.
And "your team" doesn't have to mean "your JavaScript team": official client libraries for Python, Go, Rust, C/C++, Java, C#, and Ruby speak the same protocol with the same delivery guarantees, so every service in a mixed stack plugs into the one backbone with its native tools.
A bill you can predict — and mostly, avoid
Hosted push and messaging services price by messages, connections, or both. That's a bill that grows exactly as fast as your success, and a meter running on every dashboard you leave open. TYO MQ runs as a single Node.js process on commodity infrastructure — a modest VPS carries a serious workload — and the software itself costs nothing, commercially and forever, under Apache-2.0.
Just as importantly, it's cheap to operate. There's no JVM to tune, no
ZooKeeper quorum, no cluster to keep healthy before you've shipped your first
feature. One process, one port, a /health endpoint for your load balancer,
and metrics your existing Prometheus scrapes.
Your events are your business — keep them
An event stream is a complete record of what your business does: every order, every payment, every customer action. Routing it through a third-party service is a data-governance decision, not just a technical one.
TYO MQ is self-hosted by design. Events stay on your servers, in your jurisdiction — which for Australian organisations with data-residency obligations is not a nice-to-have. And for multi-customer platforms, realms enforce tenant isolation cryptographically at the connection, not by convention in application code.
Real-time and guaranteed — without running two systems
The subtle cost of the conventional stack is the seam down the middle: the "fast" path and the "reliable" path are different systems, so every feature that needs both pays an integration tax. In TYO MQ the same produce call serves both — a live dashboard subscriber and a durable, acknowledged worker queue can consume the identical event. Features that cross that seam (most of the interesting ones do) stop being projects.
A growth path instead of a re-platform
- Day one: in-memory storage, one process, perfect for development and light production.
- When durability must survive restarts: one config line moves queues to SQLite. No new infrastructure.
- When one node isn't enough: Redis-backed clustering — multiple TYO MQ nodes sharing settings and relaying messages, with durable subscribers free to reconnect anywhere.
The API your team writes on day one is the API running on the cluster. The skills, the code, and the operational knowledge all carry forward.
Open source, minus the open-source gamble
Apache-2.0 means no licence fees, no seat counts, no usage audits, and no vendor who can re-price your infrastructure after you've built on it. The code is public at github.com/tyolab/tyo-mq — your team can read it, fix it, and fork it if we ever disappoint you.
But unlike abandoned-hobby open source, TYO MQ is a core TYO Lab product: we run it ourselves, and our engineers are available for integration, custom features, and production support — in your timezone if you're in Australia, and in plain English either way.
TYO MQ is not the answer to everything — petabyte event streaming or established AMQP estates are better served elsewhere, and we say so plainly in the comparison. The case above is for the very large class of systems that need real-time plus reliability at business scale.
Want the numbers for your specific workload? Talk to us — or skip ahead and get running in five minutes.
