Cloudflare’s lava lamps show why the strongest backup has a different failure model.
Cloudflare’s servers already had mature sources of cryptographic randomness when the company built its famous wall of lava lamps.
The extra system exists because duplicating a trusted mechanism would leave the same assumption underneath both copies. LavaRand adds entropy from a source with a different failure model.
That is the useful design principle: choose the second control partly for what it does differently from the first.
What Cloudflare gets from a wall of lava lamps
Around 100 lava lamps sit in Cloudflare’s San Francisco office. A camera captures the changing shapes, colors, reflections and movement around the display.
Cloudflare converts that image data into entropy, or unpredictable input, for a cryptographically secure pseudorandom number generator. Cryptographic systems need that unpredictability because a generator can produce enormous quantities of output only after it has been given a state an attacker cannot reconstruct.
LavaRand contributes physical entropy alongside the randomness already available from the local operating system. Cloudflare mixes the camera-derived data with previous state and local system entropy before using the result.
The important property is independence between those inputs.
The second source has a different failure model
Cloudflare built LavaRand around the possibility that a source believed to be secure could later prove weaker than expected.
A second implementation of the same mechanism would offer limited protection against that class of failure. If the weakness sits in an assumption, algorithm or implementation shared by both, duplication preserves it.
Physical entropy changes the problem because a defect in a software random-number generator cannot determine the motion of heated wax, activity in front of a camera or sensor noise produced while the image is captured. Those inputs come from a separate process with separate ways to fail.
The physical source is not better on its own. The value is in the combination, because software and physical entropy fail in different ways.
This distinction is easy to miss when designing redundant infrastructure. Teams often select the second control for capacity, compatibility and operational familiarity. Failure diversity deserves a place in that decision too.
Design the backup around the primary control’s weakness
The useful question is which weakness the second control removes from the architecture. Confirming that a second control exists tells you far less.
For LavaRand, the answer is dependence on software-generated entropy alone.
A recovery authentication method should remain usable when the primary identity platform is unavailable. An out-of-band management path should remain reachable when production routing is broken. A configuration backup should survive the credentials or management system used to administer the live device.
The requirement changes with the system, but the design process is consistent: identify the failure the primary control cannot protect itself from, then make that failure part of the specification for the secondary control.
That is a more useful way to select redundancy than simply asking for another instance of the primary system.
NetworkTigers has already covered how shared dependencies can make redundant systems fail together. The next step is architectural: remove one of those shared assumptions when choosing the fallback.
A different failure model does not mean an invulnerable one
The lava-lamp installation has obvious weaknesses. Someone could block the camera. The lamps could stop operating. Bright light could interfere with the image. Physical access creates other opportunities to disrupt the source.
Cloudflare does not have to eliminate all of those possibilities for LavaRand to be useful. The software entropy source remains available if the physical source stops contributing useful data, while the physical source adds value when the software source is under suspicion.
Each side covers a different class of weakness.
A secondary system earns its place through independence, where independence changes the outcome. Making it stronger in every dimension usually just adds complexity.
Make diversity deliberate and targeted
Cloudflare has extended its physical entropy approach beyond San Francisco.
Its London office uses double chaotic pendulums. Austin uses suspended rainbows. In March 2025, its Lisbon office added 50 wave machines whose motion supplies another changing physical input.
The installations differ because the security requirement specifies unpredictable entropy from a physical process. The particular object used to produce that entropy is secondary.
That distinction matters operationally. Standardization remains valuable. Running multiple vendors, platforms or management systems purely for diversity can increase support costs, complicate troubleshooting and create configuration drift.
The design decision comes down to identifying where sameness creates a weakness worth removing. “More diversity is safer” is the wrong heuristic.
Introduce diversity where a shared defect could defeat both the primary and secondary controls. Keep standardization where common behavior reduces operational risk without creating an unacceptable common failure.
Independence can be part of the equipment requirement
This changes how secondary infrastructure should be specified.
A spare switch, for example, is not just a hardware purchase. Its usefulness depends on whether the organization can configure and deploy it after the primary equipment has failed. NetworkTigers’ guidance on minimum hardware requirements for a small business network reflects that broader recovery requirement: hardware, configurations and the ability to restore service belong to the same plan.
Hybrid infrastructure creates similar choices because a recovery environment can use different physical infrastructure while still depending on the same identity, DNS or management service. Selecting hybrid cloud networking gear by traffic path and failure model makes those dependencies part of the design decision before hardware selection locks them in.
The goal is to decide which components can remain common. Eliminating every shared component is neither realistic nor desirable.
Count failure domains, not devices
Cloudflare’s lava lamps make an unusual implementation of a straightforward design rule visible.
Start with the weakness that matters. Then choose the secondary control partly on whether that weakness can reach it.
For cryptographic entropy, Cloudflare introduced a physical source alongside its software sources. For network infrastructure, the answer could be independent management access, separate authentication, recoverable configuration data, a different physical route or another control whose operation does not depend on the component being recovered.
That turns redundancy from a device count into a design choice.
When evaluating the fallback, ask one question: what failure can reach the primary control but stop here?
If there is no clear answer, the second control probably has not changed the failure model enough.
