Victor Bona

preprint/paper/2026-09-25

Consumer-progress acknowledgments in Redis Streams and NATS JetStream have different persistence implications even under always-synchronize append policies. We evaluate that distinction alongside recovery timing, consumer concurrency and publication cost using single-replica deployments on a two-node Kubernetes homelab. The study compares Redis 7.4.2/8.10.2 and NATS Server 2.10.24/2.15.0, preserving an original campaign and adding three deployments with fresh broker processes and stores, matched publication durations, CPU sensitivity and storage diagnostics. All 240 active follow-up recovery episodes completed, including live, deliberately unacknowledging consumers; twelve plain Redis read controls remained pending. Receipt timing followed residual eligibility plus policy-dependent excess. Redis's integrated CLAIM path exhibited greater excess than the tested explicit reclamation loop in this quiet, one-message workload. Sixteen consumers increased current memory/periodic drain throughput by 10.43–14.49 times across deployment-specific comparisons, while cycle p99 increased and driver capacity affected rates. At sixteen publishers, current periodic/memory publication ratios averaged 0.8257 for Redis and 0.8207 for JetStream. Ten of 72 planned always-profile publication trials failed (13.9%), including four warm-up failures, compared with one of 72 periodic trials and none of 72 memory trials. Timed failures returned five-second client timeouts with unknown confirmation outcomes. A compact analytical model and selected Lean-checked statements delimit the claims; full proofs and detailed results are included in the appendices. The licensed artifact retains timings, failures, configurations and reproducible analysis. These observations characterize specified policies and acknowledgment costs; they do not establish equal durability contracts, power-loss survival or hardware-independent rankings.

independently published/paper/2026-09-08

A backend application needs a composition model as well as a request handler. Its components must declare dependencies, initialize shared resources, expose routes, and coordinate operational behavior. Nidus organizes these responsibilities through explicit modules, typed providers, and controller metadata, while retaining Axum routing, Tower middleware, and Tokio execution. This paper explains the design through three separate stages: generated Rust declarations, application construction, and request execution. It describes the guarantees provided at each stage, follows a small feature from module declaration to handler invocation, and identifies the costs and limits of the abstraction. The implementation uses a runtime container keyed by Rust types and validates module structure during bootstrap. Module exports describe composition contracts; they do not enforce runtime access isolation. The account is anchored to Nidus 1.0.17 and supported by source inspection and focused executable checks.