Skip to main content

Design Philosophy

RelayX is designed to make it easy for engineering teams to add real-time features to their products without having to build, run, or deeply understand real-time infrastructure.

Most teams do not want to become experts in message brokers, fan-out systems, ordering guarantees, retries, or backpressure. They want real-time features to work so they can focus on product logic.

RelayX exists to take that infrastructure work off your plate, while still being honest about how the system behaves.

Make Real-Time Easy to Integrate​

The primary goal of RelayX is ease of integration.

You should be able to:

  • Send events
  • React to them in real time
  • Run background work
  • Share small pieces of state

without:

  • Running brokers or clusters
  • Managing persistent connections
  • Designing delivery systems from scratch
  • Debugging low-level infrastructure issues

RelayX handles these infrastructure concerns for you.

You do not need to understand how the backend is built in order to use it correctly.

Hide Infrastructure, Not Behavior​

RelayX hides infrastructure complexity, not system behavior.

It takes care of:

  • Ordering messages
  • Delivering messages to subscribers
  • Deduplicating messages and jobs
  • Redelivering work when handling fails
  • Applying backpressure when needed

But it does not hide:

  • When retries happen
  • When redelivery occurs
  • When ordering applies
  • When work can run more than once

RelayX avoids “magic” behavior that looks simple but becomes dangerous in production.

Fire-and-Forget Where It Makes Sense​

RelayX keeps producers simple.

For example, messaging is fire-and-forget from the producer’s point of view:

  • Producers send messages
  • Producers do not wait for subscribers
  • Producers do not track delivery or retries

This makes it easy to add real-time events anywhere in your system without introducing tight coupling or blocking behavior.

Subscriber handling, retries, and failures are handled independently.

Clear Rules Beat Hidden Guarantees​

RelayX prefers clear rules over clever abstractions.

Every feature has:

  • A small number of guarantees
  • Clear limits
  • Defined failure behavior

If something is guaranteed, it is written down plainly.
If something is not guaranteed, RelayX does not imply it.

This avoids situations where:

  • Things “usually work”
  • Behavior changes under load
  • Failures feel random

Clear rules make systems easier to reason about and safer to operate.

Designed for Failure From Day One​

RelayX assumes failures are normal.

This includes:

  • Subscriber crashes
  • Worker restarts
  • Network disconnects
  • Slow consumers
  • Load spikes

RelayX behavior is defined with these situations in mind, not added later as an afterthought.

For example:

  • Messages are redelivered when subscriber handling fails
  • Jobs are redelivered when workers crash or fail to acknowledge
  • Ordering and deduplication rules stay the same during retries

Failure does not change the rules. It just triggers documented behavior.

Backend Guarantees, Application Responsibility​

RelayX takes responsibility for infrastructure-level guarantees.

RelayX guarantees things like:

  • How messages are ordered
  • When messages or jobs are redelivered
  • What deduplication means
  • When work is considered complete

RelayX does not take responsibility for:

  • Business correctness
  • Domain rules
  • Exactly-once side effects
  • Coordinating external systems

This split is intentional.

RelayX handles delivery and storage.
Your application handles correctness.

Small Tools With Narrow Purpose​

RelayX provides a small number of tools, each with a clear role:

  • Messaging for real-time events
  • Queues for background work
  • Key-Value Store for shared state

These tools are not combined into a single abstraction.

This keeps:

  • Each tool easier to understand
  • Failure behavior easier to predict
  • Misuse easier to spot

Complex systems are built by composing simple parts, not by hiding complexity inside one large feature.

Predictable Under Load​

RelayX is designed to stay predictable when systems are under stress.

It avoids designs that:

  • Block progress waiting on slow consumers
  • Hide backpressure
  • Depend on global coordination to function

When load increases, things may slow down, but behavior should not become confusing or inconsistent.

Predictability matters more than peak



Need Help?

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