Skip to main content

What RelayX Is

RelayX is a real-time messaging platform that helps systems send events, run background work, and persist data across applications.

RelayX is built for production systems. It assumes things will go wrong: processes crash, networks drop, handlers fail, and load spikes. RelayX does not try to hide these realities or smooth them over with vague guarantees. Instead, it tells you exactly what happens, step by step, and treats that behavior as a contract.

This page explains what RelayX actually does, in plain terms.

RelayX Is a Set of Simple Tools With Clear Rules​

RelayX provides a small set of tools:

  • Messaging (Pub/Sub) to send events to subscribers
  • Queues to run background jobs
  • Key-Value Store to persist data across applications

Each tool has clear rules about:

  • Ordering
  • Deduplication
  • Retries
  • When work is considered done

RelayX does not mix these tools together or hide their behavior. You choose which tool to use, and you get exactly the rules documented for that tool.

RelayX Is Built Around Messaging​

Messaging is the core of RelayX.

Messaging lets producers send messages to a topic and lets subscribers receive them. From the producer’s point of view, messaging is fire and forget. A producer sends a message and does not wait for subscribers to process it.

What “Ordered” Means in RelayX​

When RelayX says messages are ordered, it means this:

  • When a message reaches the RelayX backend, it is given a timestamp
  • Within a topic, messages are sorted by that timestamp
  • Subscribers receive messages in that order

This gives you a clear, stable ordering rule that does not depend on:

  • Client clocks
  • Network timing
  • Which producer sent the message

Ordering applies:

  • To messages delivered to a subscriber, based on backend-assigned timestamps

Ordering does not apply:

  • As a merged, observable order across different topics
  • Across different RelayX accounts

What “Deduplicated” Means in RelayX​

RelayX deduplicates messages at the backend.

This means:

  • A message is stored once
  • A message is sequenced once
  • RelayX does not create duplicate backend records

Deduplication protects you from internal retries and backend failures causing duplicate ingestion.

Deduplication does not mean:

  • Your subscriber code will only run once
  • Your business logic is exactly-once

If subscriber code crashes before finishing, the same message will be delivered again. That is expected.

When Messages Are Redelivered​

RelayX does not randomly resend messages.

Messages are redelivered only when subscriber handling fails.

This includes cases where:

  • The subscriber process crashes
  • The subscriber disconnects while handling a message
  • The subscriber fails before completing handling

Redelivery does not happen during normal operation. It is a direct signal that handling did not complete successfully.

When redelivery happens:

  • The same message is delivered again
  • Ordering within the topic is preserved

When a Message Is Considered “Done”​

In RelayX, a message is not done just because it was delivered.

A message is done only when:

  • Subscriber code finishes handling successfully

If subscriber code does not finish, RelayX assumes the message was not handled and will deliver it again.

This rule is simple and consistent. It avoids guessing and hidden behavior.

RelayX Also Supports Background Work​

RelayX Queues are used for background jobs.

Queues follow similar ideas:

  • Jobs are delivered at least once
  • Jobs are deduplicated by the backend
  • A job is only complete after it is acknowledged
  • Jobs are redelivered only when a worker crashes or fails to acknowledge in time

Queues are for background work, not workflows or scheduling systems.

RelayX Can Store Shared State​

RelayX includes a Key-Value Store for small pieces of shared state.

This store:

  • Persists values until deleted
  • Is scoped per RelayX account
  • Uses last-write-wins behavior

If two clients write to the same key at the same time:

  • One value will overwrite the other
  • The earlier value may be lost

This is expected behavior. The Key-Value Store is not a database.

RelayX Draws Clear Responsibility Lines​

RelayX is responsible for:

  • Ordering messages per topic
  • Deduplicating messages and jobs at the backend
  • Delivering messages and jobs
  • Redelivering work when handling fails
  • Persisting key-value state with clear rules

RelayX is not responsible for:

  • Business correctness
  • Domain rules
  • Exactly-once side effects
  • Making retries safe
  • Coordinating with external systems

These responsibilities belong to your application.

RelayX Is Designed for Failure​

RelayX assumes:

  • Subscribers crash
  • Workers restart
  • Networks disconnect
  • Load fluctuates

Its rules are designed to keep working when these things happen.

Instead of pretending failures are rare, RelayX makes failure behavior visible and predictable.

What It Means to Use RelayX​

Using RelayX means accepting these facts:

  • Ordering is real and scoped
  • Deduplication is backend-level
  • Redelivery means handling failed
  • Your code must handle retries safely

RelayX does not promise magic.
It promises clarity.

That clarity is what makes RelayX useful in production.



Need Help?

Join our Discord server, post your concern & someone from our team will help you out ✌️