Choosing a Quantum Randomness Provider: What We Measured, and What We Built First

When we wrote about bringing quantum randomness into FeelTrack, we said we were evaluating providers. That evaluation is done. We’re building on Outshift by Cisco’s QRNG API.

This post is about how we chose, what we measured, and why the first code we shipped was the least interesting part of the entire project.

Why not just pick one and go

A quantum random number generator is an unusual dependency. Most APIs you integrate are things you could, in principle, build yourself — slower or worse, but you could. A QRNG is not like that. The whole value proposition is that the numbers come from a physical process no algorithm can imitate. If the pipe from that process to your application is unreliable, you don’t degrade gracefully to slightly-worse randomness. You degrade to lying.

That framing drove the whole evaluation. We didn’t ask “which provider is fastest.” We asked “which provider can we be honest about.”

What we measured

We tested against a live key rather than trusting documentation. Four things mattered:

Latency, warm and cold. A warm request came back in roughly six tenths of a second. The first request after a quiet period took closer to four seconds. That gap is the interesting number — it means you cannot put this call in the path of anything a person is waiting on. Whatever we built would have to be asynchronous from the start.

Batching behaviour. A single request can return up to a thousand values, and doing so was barely slower than asking for one. That’s a strong argument for fetching in bulk.

Rate limiting. We fired requests back to back to see where the throttle was. There wasn’t one — at least not on frequency.

The quota. This is where the evaluation earned its keep.

The finding that changed the design

The quota is not measured in requests. It’s measured in bits.

That sounds like a technicality. It isn’t. It inverts the usual optimisation. Normally you batch requests to conserve a call budget — fewer, bigger calls, same data, lower cost. Here, batching saves latency and saves nothing at all on quota. Twenty values cost the same whether you fetch them in one request or twenty.

Which means the only lever that actually matters is how much randomness you consume per user action, and that’s a product decision, not an engineering one. A design that attaches a quantum value to each of the twenty emotions in a PANAS check-in costs twenty times more than one that attaches a single value to the check-in as a whole. Same feature, superficially. Twentyfold difference in how many people we can serve.

We only learned that by hitting the limit deliberately during testing. No response header advertises it. Nothing in the integration guide would have told us. If we’d designed the feature first and measured second, we’d have built something that worked beautifully in development and hit a wall the first busy day in production.

What we shipped first

Not the feature. The alerting.

API keys for this service expire every ninety days. When ours lapses, quantum values stop being available — and the failure is silent. No crash, no error page, nothing a user would report. The feature would simply stop being quantum, and the only way we’d find out is if someone happened to look.

So the first thing we built and deployed was a scheduled job that emails us every day for the last seven days a key is valid, and keeps emailing after it expires. It does nothing else. It has no user interface. Most days it does nothing at all.

It’s genuinely the least exciting code in the project, and we’re glad it’s the part that’s already running in production. The failure mode of an alerting system is that its silence looks exactly like everything being fine — which is a good reason to build it while you’re still paying attention, rather than after something has quietly broken.

What’s next

The provider is chosen and the operational groundwork is in place. What comes next is the part that’s actually visible: attaching quantum values to individual emotion responses, and asking people what they make of them.

We’ll write about that as it ships — including the results, whatever they turn out to be.