The 3D version renders the HSM as a boundary that objects fly toward and away from at a fixed animation duration, with no notion of the hardware server actually being busy. This 2D counterpart is a genuinely different, independently-computed model: the HSM crypto core is a real single-server M/M/1 queue, and "how stale is my data" is a real exponential exposure-window decay — neither exists in the 3D scene at all.
Arrivals: interarrival ~ Exponential(λ) (new encryption requests)
Service: duration ~ Exponential(μ) (HSM wrap/re-wrap op, one at a time, FCFS)
ρ = λ/μ, Lq = ρ²/(1−ρ), L = ρ/(1−ρ), Wq = ρ/(μ−λ) [standard M/M/1 results]
Exposure window per object after a rotation:
P(still on old KEK at time t) = (1−p)·e^(−τ·t)
p = fraction proactively re-wrapped instantly at rotation (0.18)
τ = per-object "lazy touch" rate — first access after rotation re-wraps it
Both relationships were checked numerically before shipping (400,000+ simulated seconds / objects, using the same exponential-sampling primitives as this page): the M/M/1 queue-length/wait formulas matched a fine-grained frame-stepped simulation to within ~0.1–0.3% once the frame step was small, converging away as the step shrinks (a coarser step, closer to what a live 60fps page actually runs at, reads a few–15% high — a known, harmless discretization bias of any fixed-timestep queue simulation, not a modeling error, which is why both the theoretical and the live-measured numbers are shown side by side above rather than only one). The exposure decay formula matched a 400,000-object Monte Carlo run to within 0.3% at every checkpoint from t=0 to t=60s.
- Encryption request rate λ — Poisson arrivals of new objects needing a fresh DEK wrapped by the HSM.
- HSM crypto throughput μ — how many wrap/re-wrap operations per second the single hardware server can perform; push λ close to or above μ to watch the queue (and true wait time) blow up, exactly as M/M/1 theory predicts.
- Key rotation interval — how often the KEK version increments. A fraction of stored objects are proactively re-wrapped on a separate maintenance path (still shown as a rewrap job on the ring); the rest sit in the "stale" (old-KEK) pool until their own lazy-touch clock fires.
- Lazy access rate τ — how often each stored object is naturally read/written; every access to a stale object triggers a real re-wrap job, which is exactly what makes the exposure window decay exponentially rather than needing an all-at-once re-encryption sweep.
- Unauthorized attempt rate — simulated extraction attempts against the hardware boundary; every one is blocked and logged, since the KEK never leaves the module (same guarantee as the 3D model, unchanged).
Where this deliberately differs from the 3D model: there is no fixed 0.75s wrap animation here — service time is a real random variable, congestion is a real emergent property of λ vs. μ, and "exposure" is tracked per-object with a real survival-time distribution instead of a one-shot 18% sample at the instant of rotation.