What RelayX Is Not
This page explains what RelayX is not designed to do.
These are not missing features or future plans. They are deliberate limits. RelayX stays reliable by being clear about where it stops.
If you assume RelayX does something that is not written down as a guarantee, that assumption will eventually break in production.
RelayX Is Not a General-Purpose Distributed Platform
RelayX is not a system that tries to solve every distributed systems problem for you.
It does not provide:
- A single abstraction that covers messaging, storage, and execution
- Automatic coordination between different parts of your system
- End-to-end correctness guarantees across multiple services
- A “just works” model that hides failure
RelayX gives you small tools with clear rules. You decide how to combine them.
If you are looking for a system that designs your architecture for you, RelayX is not that system.
RelayX Is Not a Database
RelayX includes a Key-Value Store, but it is not a database.
It does not provide:
- Transactions
- Atomic updates across multiple keys
- Queries or indexes
- Strong consistency
- History or versioning of values
The Key-Value Store uses last-write-wins behavior.
If two clients write to the same key at the same time:
- One write will overwrite the other
- The earlier value may be lost
- RelayX will not warn you
This is expected behavior.
If your system needs durable records, queries, or strong consistency, you should use a real database and treat RelayX as a supporting system.
RelayX Is Not a Workflow Engine
RelayX Queues are for background jobs, not workflows.
RelayX does not provide:
- Scheduled or delayed jobs
- Cron-style execution
- Job dependencies
- Multi-step workflows
- Long-running state machines
- Automatic rollback or compensation
Queues exist to:
- Run work outside request paths
- Retry work when workers fail
- Spread work across workers
If you try to build workflows using queues and keys, things may appear to work at first and then fail badly under retries or crashes.
RelayX Is Not an Exactly-Once System
RelayX does not guarantee exactly-once execution of your code.
Even though RelayX:
- Orders messages
- Deduplicates messages and jobs at the backend
- Redelivers messages only on handling failure
Your handler code can still run more than once.
This happens when:
- A subscriber crashes mid-handling
- A worker dies before acknowledging a job
- A process restarts at the wrong time
Backend deduplication prevents duplicate ingestion.
It does not prevent duplicate execution of business logic.
If your system assumes “this code runs once and only once”, that assumption is unsafe.
RelayX Is Not a State Machine
RelayX does not manage state transitions for you.
It does not:
- Enforce invariants
- Validate state changes
- Prevent conflicting updates
- Resolve conflicts beyond last-write-wins
RelayX stores values and delivers messages. It does not know what those values or messages mean.
If your system needs strict rules around state changes, those rules must live in your application.
RelayX Is Not a Streaming Analytics System
RelayX delivers events. It does not analyze them.
RelayX does not provide:
- Aggregations
- Windows
- Event-time processing
- Stream joins
- Queryable stream state
If you need analytics or stream processing, use a system built for that and feed it with events from RelayX if needed.
RelayX Is Not a Cache Replacement
RelayX is not a drop-in cache.
The Key-Value Store does not provide:
- Automatic eviction
- Time-to-live guarantees
- Memory limits
- Cache invalidation mechanisms
Keys stay until you delete them.
If you need a cache with eviction and TTL, use a cache designed for that job.
RelayX Is Not a Safety Net for Bad Assumptions
RelayX does not make unsafe designs safe.
It does not:
- Retry your business logic correctly for you
- Detect partial side effects
- Guess whether work should be retried
- Hide failure from your code
RelayX retries delivery, not correctness.
If your code makes unsafe assumptions about retries or failures, RelayX will expose those assumptions under load or during crashes.
RelayX Is Not Opinionated About Your Architecture
RelayX does not force:
- Microservices or monoliths
- Event sourcing or request-based designs
- Specific retry strategies
- Specific idempotency patterns
It gives you tools and rules.
You decide how to use them.
RelayX will not stop you from building something fragile. It also will not stop you from building something solid.
Why These Limits Exist
RelayX stays predictable by refusing to promise things it cannot guarantee under failure.
Features that would:
- Hide retries
- Blur responsibility
- Mask partial failure
- Pretend correctness is automatic
are intentionally left out.
The goal is not to do everything.
The goal is to behave clearly when things go wrong.
When RelayX Is the Wrong Choice
RelayX is the wrong tool if your system depends on:
- Exactly-once execution
- Implicit coordination
- Automatic workflows
- Strong transactional guarantees
- Hidden retries and recovery
RelayX works best when you want:
- Clear rules
- Visible failure
- Predictable behavior
- Control over correctness
Those limits are not weaknesses.
They are what make RelayX reliable in production.
Join our Discord server, post your concern & someone from our team will help you out ✌️