Skip to main content

Key-Value Store

1. Concept Overview​

The RelayX Key-Value Store is used to store and retrieve small pieces of shared state.

It exists to solve a simple problem:

Allow different parts of a system to read and write shared values with low latency.

The Key-Value Store is intentionally limited. It is not a database, not a cache with eviction policies, and not a transactional system. It provides a small, predictable set of behaviors that are easy to reason about under failure.

2. How to Think About It​

Think of the Key-Value Store like this:

  • Values are stored under a string key
  • Any client can read a value by key
  • Any client can write a value to a key
  • Writes overwrite previous values
  • The latest write wins

Important mental model points:

  • The store is scoped per RelayX account
  • Values are persistent until explicitly deleted
  • Concurrent writes are allowed
  • There is no locking or coordination
  • The system always keeps one value per key

The Key-Value Store is about shared state, not coordination or correctness guarantees across multiple operations.

3. What Happens Step by Step​

This is what happens when interacting with the Key-Value Store:

Writing a value​

  1. A client writes a value to a key.
  2. The RelayX backend receives the write.
  3. The backend stores the value for that key.
  4. If a value already exists, it is overwritten.
  5. The write completes.

Reading a value​

  1. A client reads a key.
  2. The RelayX backend looks up the key.
  3. If a value exists, it is returned.
  4. If no value exists, the key is reported as missing.

Deleting a value​

  1. A client deletes a key.
  2. The RelayX backend removes the value.
  3. Future reads of the key return no value.

There is no multi-step transaction or conditional logic in any of these flows.

4. Guarantees​

RelayX provides the following guarantees for the Key-Value Store:

  • Each key stores exactly one value.
  • Values persist until explicitly deleted.
  • Writes overwrite existing values for the same key.
  • The most recent successful write determines the stored value.
  • Reads return the latest stored value known to the backend.

Anything not listed here is not guaranteed.

5. What This Does Not Do​

The Key-Value Store does not:

  • Provide transactions
  • Support conditional updates
  • Offer locking or coordination primitives
  • Track history or versions
  • Act as a database

It stores the latest value only.

6. Correct Ways to Use This​

The Key-Value Store works best when used for:

  • Configuration values
  • Feature flags
  • Small pieces of shared state
  • System-wide toggles

Good usage patterns:

  • Treat values as replaceable
  • Design for overwrites
  • Handle missing keys gracefully
  • Avoid relying on write ordering

7. Common Mistakes​

Treating the store like a database​

The Key-Value Store does not support queries, joins, or transactions. Using it this way will lead to fragile designs.

Assuming writes are coordinated​

Concurrent writers are not synchronized. Last-write-wins means earlier values can be lost.

Using it for critical state​

Do not store state that requires strict correctness or coordination. This store favors simplicity over guarantees.

8. When This Is the Wrong Tool​

The Key-Value Store is the wrong choice if you need:

  • Strong consistency guarantees
  • Transactions or conditional updates
  • Historical data
  • Complex querying
  • Coordination between writers

In those cases, use:

  • A database
  • A coordination service
  • Application-level locking or state management

The Right Mental Model​

If you remember one thing:

The Key-Value Store holds the latest value for a key, and newer writes replace older ones.

Design with that assumption, and the system will behave predictably.



Need Help?

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