VOXELL
Log in Create free account
BLOG
INFRA FOUNDER'S NOTE

Redis Is Not a State Sync Layer

Jonathan Corners

If your real-time path is Redis pub/sub plus glue you wrote yourself, you don't have a product. You have a science project. Lux is what that path becomes when you delete the glue.

Redis is excellent at being Redis. Cache. Counters. Sessions. A blunt instrument with good taste.

What Redis is not is a real-time application state product. Teams keep using it that way anyway, because it is already in the VPC and the alternative looks like Kafka or a managed realtime tax.

That is how you end up with this stack:

  1. Publish a message to a channel.
  2. Hope every subscriber is still connected.
  3. Rebuild auth, reconnect, offline queue, versioning, and a browser SDK yourself.
  4. Discover six months later that “we use Redis for realtime” means “we own a private messaging framework with no tests and one on-call engineer who understands it.”

Lux exists because that path is a product category with one honest answer: a purpose-built sync broker, not a cache with feelings.

What we measured

Three layers. Do not mix them up. The industry loves mixing them up.

Layer What it is Lux (measured)
In-memory primitive Read/write inside the broker process ~12 ns read, ~50 ns write, 0 allocs
Broker hot path Real HTTP + WebSocket, local loopback ~27 µs write ack p50, <120 µs p99
Private AWS path Separate EC2 client → broker, same subnet ~390 µs p50, ~1.1 ms p99

No message queue on that path. No database pre-read before ack. No phone-home to Voxell on a sync. The hot path is RAM and fencing. Durability is async write-behind if you want it. Ack is not the same thing as durable. Anyone who tells you otherwise is selling a fiction you will pay for in an outage.

Those numbers are not “internet latency.” They are not “your phone to us-east-1.” They are the product boundary that matters when you are choosing between standing up a system and shipping a feature.

Redis is the wrong layer for this job

Redis pub/sub is fire-and-forget messaging. Application state needs:

  • A current value, not a stream of maybe-delivered events
  • A browser client that works offline and reconciles
  • Versioning / CAS so two tabs do not silently clobber each other
  • Reconnect without a thundering herd
  • Auth and tenant isolation that is not a weekend project
  • A bill that does not scale with every fan-out message

You can bolt all of that onto Redis. People do. Then they have a company-specific real-time platform that nobody outside the team can hire for, document, or buy through procurement.

Lux is that platform, productized:

  • npm i @voxell/lux — ~1–2.5 KB client, local-first reads, WebSocket push
  • Buyer-deployed Go broker — runs in your AWS account
  • Open source path for the client and edge shape
  • Commercial path on AWS Marketplace when procurement needs a real vendor

Open source and Marketplace are the same product story

The open source surface is the honest wedge:

Start free. Point it at Cloudflare KV or a broker you run. When security, support, licensing, and AWS spend need a paper trail, the same architecture shows up as a Marketplace subscription with a signed broker license verified offline on boot — no hot-path network call to Voxell.

That is not “open core theater.” The hot path never depended on us. We sell the control plane, the license, and the operational proof. You keep the state.

When not to use Lux

Use Kafka, MSK, or a real log when you need event history, replay, and stream processing.

Use Redis when you need a cache or shared data structure.

Use Firebase when you want a hosted everything-bag and you are fine with that trust and cost model.

Use Lux when the job is: the current state of this document / board / agent / dashboard must be correct and live across clients, in infrastructure we control, without standing up a queue cluster.

The shortlist test

If an engineer is already muttering any of these, Lux belongs on the list:

  • “Kafka is too much for UI state.”
  • “Redis pub/sub still leaves us writing a protocol.”
  • “Firebase is not an AWS procurement fit.”
  • “Pusher/Ably is fine until the invoice.”
  • “We just need WebSocket state sync that does not become a second product.”

We do not need everyone to know the brand. We need the shortlist at the moment the wrong layer is already expensive.

Product: voxell.ai/lux
Client: npm i @voxell/lux
AWS Marketplace: Lux Sync by Voxell (SaaS registration / buyer-deployed broker)

If you are evaluating, open two browser windows against a broker and watch state land. The demo is the argument. Everything else is packaging.