Slizen v0.2.3-rc.1

Slizen v0.2.3-rc.1

This is a prerelease for external staging trials, not a production-readiness claim.

Release identity:

• tag: v0.2.3-rc.1
• commit: 7662a1fb5974a6fc369ca486d2a59c85f68cd3b7
• image: ghcr.io/slizendb/slizen@sha256:e30ad22f4cb23462af9f05322ff97d6796fc521e2e80dc181c42107e4193b92a
• platforms: linux/amd64, linux/arm64

The latest and 0.2 aliases remain on verified stable v0.2.2:
sha256:7989b6ff17659b3f1b2f1d3feec8af6422b48f1f5486eb77247a5c82ba86b627.

What changed

• Bounded two-hit cache admission reduces cold-start origin reads without increasing the configured global cache limits.
• Supported proxied writes invalidate before dispatch and use cache epochs so overlapping reads cannot restore superseded values.
• Exact option-free SET can refresh an already admitted cache-policy key after upstream success; it does not admit cold keys.
• slizenctl compatibility report provides a deterministic offline command-contract preflight.
• Observe-first Helm/Kubernetes packaging now includes default-deny ingress, explicit peer controls, bounded resources, staging values, dashboards, alerts, and rollback-oriented operator documentation.
• Metrics now cover active connections, configured cache bounds, miss reasons, tracker-capacity drops, and Go/process collectors.
• Release artifacts are self-contained and bound to the exact tag, commit, image digest, and provenance.

Exact-image evidence

The published digest was tested against Valkey 8.1.9 with four isolated,
100,000-operation scenarios:

Scenario	Physical origin GET reduction	Cache hit ratio	Direct p99	Slizen p99
uniform	97.516%	97.487%	1.082 ms	1.819 ms
skew-80/20	97.969%	97.959%	1.211 ms	1.889 ms
skew-99/1	99.201%	99.182%	1.530 ms	2.049 ms
moving-flash	99.130%	99.096%	7.108 ms	8.979 ms

All scenarios had valid physical INFO commandstats evidence, zero request
failures, zero value mismatches, zero validation failures, and zero validation
mismatches.

The direct path had lower p99 in every scenario. The defensible product claim
is reduced upstream GET load for these exact workloads, not that Slizen
makes Redis or Valkey faster and not that every workload receives a 99%
reduction.

Artifacts

• slizen-0.2.3-rc.1.tgz — release-bound Helm chart with bundled operator docs
• slizen-observe-sidecar-0.2.3-rc.1.yaml — raw observe-first sidecar pattern
• release-evidence-manifest.json — version/commit/image/artifact identity
• SHA256SUMS — checksums for every attached evidence file
• exact-image workload, benchmark, status, audit, hot-key, and demo evidence

The image, Helm chart, and raw sidecar manifest have GitHub-native build
provenance attestations.

Known limitations

• Single-node developer preview; Redis or Valkey remains the source of truth.
• Direct writes to the origin can remain stale until local TTL expiry.
• Limited Redis command compatibility.
• No Redis Cluster or Sentinel discovery/failover.
• No downstream RESP authentication/TLS, no upstream Redis/Valkey TLS, and no built-in admin API authentication.
• Every sidecar replica has independent disposable cache state.
• External self-service staging is not considered proven until an unfamiliar operator completes the install, rollback, failure drills, and soak gate without maintainer intervention.

Slizen v0.2.2 — Proxy tax reduction and benchmark attribution

Slizen v0.2.2 — Proxy tax reduction and benchmark attribution

Slizen v0.2.2 keeps the v0.2 single-node developer-preview scope while reducing verified cache-hit overhead, removing avoidable delay from hot-key promotion, and making workload evidence easier to interpret. Redis or Valkey remains the source of truth.

What changed

• Redis-backed GET misses now fetch the value and remaining TTL in one pipelined round trip. Missing keys, cancellation, Redis reply errors, and transport failures retain explicit handling.
• The verified local-cache GET path avoids miss-only timeout allocation, redundant hotness and cache-stat locks, generic command parsing, and repeated Prometheus label lookup.
• Steady-state handler drain accounting now uses a double-checked atomic reservation and one completion critical section instead of three global mutex handoffs. Deadline syscalls no longer run while holding the global drain mutex, and a handler that races with drain startup is either accounted for or rolled back without executing a command.
• A key can enter HOT during the final required qualifying window once promotion is mathematically unavoidable. The configured EWMA, threshold, consecutive-window hysteresis, and cooldown rules are unchanged; the tracker no longer waits for a redundant wall-clock boundary.
• slizenctl benchmark workload now reports separate read, write, ordering-wait, and final-validation latency distributions. It also records generated operation attempts and whether issuance stopped at the request or duration limit while retaining the aggregate latency fields for schema compatibility.

Upgrade notes

• No configuration keys were added or removed. Existing v0.2.1 observe-first and selective-cache configurations remain applicable.
• Hot keys may promote earlier within their final qualifying window. Review alerting or tests that assumed state transitions occurred only at a completed window boundary; thresholds, hysteresis, demotion, and cooldown behavior have not been relaxed.
• Upstream GET misses still require both GET and PTTL permissions. v0.2.2 sends those commands as one pipeline rather than two serial round trips, so restrictive Redis or Valkey ACLs must continue to allow both.
• Workload JSON consumers should accept the additive operation_attempts, termination_reason, and per-operation latency objects. The top-level p50_ms, p95_ms, and p99_ms fields remain mixed aggregate distributions; use the new objects when distinguishing command time from harness ordering wait and final validation.
• Local cache and hotness state remain disposable. Restarting Slizen still starts those states cold and does not require data migration.

Published artifacts

• The annotated v0.2.2 tag resolves to commit 74a12767deb72db9bc78bebd807cbe8717fa572c.
• The immutable multi-architecture image index is ghcr.io/slizendb/slizen@sha256:7989b6ff17659b3f1b2f1d3feec8af6422b48f1f5486eb77247a5c82ba86b627, with linux/amd64 and linux/arm64 manifests. The v0.2.2, 0.2.2, 0.2, and latest aliases were independently verified against that index digest.
• The exact-commit public CI, 100,000-key extended validation, and release image workflow completed successfully.
• GitHub-native provenance verifies for the immutable digest. The checksummed image evidence bundle and both extended-validation artifacts are attached to the GitHub Release.

Install and attest

docker pull ghcr.io/slizendb/slizen@sha256:7989b6ff17659b3f1b2f1d3feec8af6422b48f1f5486eb77247a5c82ba86b627
docker image inspect ghcr.io/slizendb/slizen@sha256:7989b6ff17659b3f1b2f1d3feec8af6422b48f1f5486eb77247a5c82ba86b627 \
  --format '{{index .Config.Labels "org.opencontainers.image.revision"}}'
gh attestation verify oci://ghcr.io/slizendb/slizen@sha256:7989b6ff17659b3f1b2f1d3feec8af6422b48f1f5486eb77247a5c82ba86b627 \
  --repo slizendb/slizen

The revision label must equal the released commit above. The rolling 0.2 alias is convenient for discovery but is not an immutable release identity.

Evidence contract

The v0.2.2 release gate runs the exact uniform, skew-80-20, skew-99-1, and moving-flash scenarios with 1,000 keys, concurrency 32, a 95/5 read/write mix, and 128-byte values. Each direct-origin and Slizen phase must reach exactly 100,000 generated operation attempts and report termination_reason: "request_limit"; 30 seconds is a safety cap, not the intended stopping condition. The moving flash key advances every 20,000 generated operations.

Every scenario must have isolated, monotonic status evidence, zero request failures, zero value mismatches, and zero final-validation failures or mismatches. The combined read and write latency sample count must equal generated operation attempts, ordering-wait samples must match their command class, and final-validation samples must match validation reads. The stable 99/1 scenario must additionally record real cache hits and positive measured origin GET reduction. There is deliberately no shared-runner latency or capacity threshold.

Image-bound release evidence

The published-image run used the exact digest above with Valkey 8.1.9 on a GitHub-hosted Linux/amd64 runner. Every direct-origin and Slizen phase reached exactly 100,000 generated operation attempts with termination_reason: "request_limit". All four scenarios recorded zero request failures, value mismatches, final-validation failures, and final-validation mismatches; the complete sample-accounting contract passed.

• In the stable 99/1 scenario, upstream GETs fell from 94,961 direct to 9,707 through Slizen, an 89.778% reduction, with a 73.628% cache-hit ratio. Attributed read p99 was 2.137 ms through Slizen versus 1.460 ms direct, so this is an origin-load result rather than a claim that the proxy was faster.
• In the moving-flash scenario, upstream GETs fell from 94,956 to 8,735, a 90.801% reduction, while the cache-hit ratio was 13.451%. Request coalescing contributes substantially to that gap, so it must not be presented as cache-hit reduction alone. Attributed read p99 was 1.166 ms through Slizen versus 0.801 ms direct.
• In the separate single-hot-key image test, the fully warm phase served 20,000 requests with 100% cache hits and zero upstream GETs. Its p99 was 1.241 ms through Slizen versus 1.191 ms direct; this narrow synthetic best case is not a production-capacity result.

See the image-bound workload JSON, image benchmark JSON, and checksummed manifest attached to the release. The separate 100,000-key workload and five-run high-cardinality benchmarks also passed without failures or mismatches. That workload used a duration safety cap and is not a fixed-request throughput comparison or published-image run.

Pre-release local optimization evidence

These results were recorded on an Apple M5 with Go 1.26.5 and describe the tested revisions, host, configuration, and synthetic workloads only. They are not tagged-image evidence or a production capacity claim.

• In corrected in-process cache-hit benchmarks, the serial handler median fell from 488.0 to 159.2 ns/op and the concurrent dispatch median fell from 918.8 to 531.6 ns/op. Benchmark allocations fell from 320 B and 8 allocations per operation to 16 B and 2 allocations for the serial path, and to 15 B and 2 allocations for the concurrent path.
• Against drain-accounting baseline 86623ef, handler bookkeeping medians were 54.5%, 70.7%, and 69.0% lower at local GOMAXPROCS=1, 10, and 32. In ten counterbalanced GOMAXPROCS=10 dispatch pairs, every pair favored the candidate and the median fell from 538.6 to 383.75 ns/op, with allocations unchanged at 15 B and 2 allocations per operation.
• Across three local Docker hot-key repeats, a fully warm Slizen served 100% cache hits with zero origin GETs. Median p99 was 1.277 ms through Slizen versus 1.182 ms direct, a 0.095 ms tax. Three complete request-bound workload gates measured 71.4–79.2% origin GET reduction in the mixed 99/1 scenario with a 0.23–0.52 ms read-p99 tax.
• In five alternating 99/1 Docker A/B pairs against baseline e35792a, guaranteed final-window promotion raised the median cache-hit ratio from 36.00% to 61.61%, raised median origin GET reduction from 72.57% to 85.92%, and reduced median upstream GETs from 26,044 to 13,371. Median Slizen read p99 was effectively flat at 1.364 versus 1.368 ms, and all ten benchmark invocations reached the request limit with zero failures, value mismatches, or final-validation mismatches.
• The earlier-promotion change added 0.76 ns/op, or 3.1%, to the steady-state hotness observation median with zero allocations. A separate moving-flash gate measured substantial origin reduction, but most of that saving came from request coalescing, so it is not presented as a cache-only result.

The in-process benchmarks exclude RESP parsing, TCP, socket I/O, operating-system deadline syscalls, and upstream work. The Docker results are single-host synthetic measurements, and the wider adaptive-workload variance is why v0.2.2 makes no universal latency, throughput, or origin-reduction promise. Reproduce comparisons with matching limits, termination reasons, runtime, configuration, seed, and workload shape.

Known limitations

• Slizen remains a single-node developer preview. It is not a durable database, distrib...

Slizen v0.2.1 — Launch hardening

Slizen v0.2.1 — Launch hardening

Slizen v0.2.1 keeps the v0.2 single-node developer-preview scope and hardens its defaults, resource admission, workload evidence, and release supply chain. Redis or Valkey remains the source of truth.

What changed

• Fresh installs start in observe mode: supported reads are forwarded and measured, never stored or served locally.
• Selective caching now has a documented safe pattern: global cache mode, an empty-prefix observe catch-all, and explicit narrower cache policies.
• When no stable HMAC key is configured, Slizen generates a cryptographically random process-local secret instead of using a shared placeholder. It is never logged; anonymized IDs change after restart.
• RESP commands have configurable, hard-capped byte, argument, and MGET-key admission limits; concurrent accepted connections are bounded.
• Cache status reads no longer discard expired values that may still be eligible for an explicitly configured stale-grace fallback. Reported cache entries and bytes describe bounded retained storage.
• Hot-key summary counts no longer scan the full tracker on every status request, and at-capacity unseen-key admission now uses bounded deterministic eviction instead of an O(n) scan under the tracker lock.
• Shared GET refills survive an individual caller cancellation but are capped by the stricter proxy/upstream read timeout and canceled when the service closes.
• Rejecting an oversized pipelined command now discards the already parsed tail before closing the connection, so a trailing mutation cannot reach the origin.
• The workload benchmark orders same-key writes and reads, verifies deterministic key-and-write-version payloads, and checks every written key's final generation. value_mismatches and validation counters are additive JSON evidence; any mismatch invalidates the scenario.
• Release Actions and container bases are digest/SHA pinned, Dependabot update paths are declared, OCI labels include Apache-2.0, and the canonical license plus notice ship in the image.
• The minimum Go toolchain and pinned builder are 1.26.5, which includes the standard-library fix for GO-2026-5856.
• A tag must pass the full source release gate before its multi-architecture image is published. The workflow then attaches GitHub-native provenance and generates checksummed evidence from the exact image digest.

Upgrade notes

• Configurations that explicitly set mode = "cache" keep cache behavior. Configurations that omitted mode now start observe-only and require an explicit promotion decision.
• Keep an empty-prefix observe policy when enabling global cache mode for selected prefixes; unmatched keys otherwise inherit the global mode.
• If anonymized key IDs must survive restart, load privacy.key_hash_secret or SLIZEN_KEY_HASH_SECRET from a secret manager. Otherwise leave it unset.
• Review the new proxy.max_command_bytes, proxy.max_command_args, proxy.max_mget_keys, and proxy.max_connections defaults before high-concurrency staging.
• cache_entries and cache_bytes are retained-memory counters. An expired entry may remain bounded in storage until access or eviction, including during stale grace.

Install and verify

docker pull ghcr.io/slizendb/slizen:0.2.1
docker image inspect ghcr.io/slizendb/slizen:0.2.1 \
  --format '{{index .Config.Labels "org.opencontainers.image.revision"}}'
gh attestation verify oci://ghcr.io/slizendb/slizen:0.2.1 \
  --repo slizendb/slizen

Use the digest from release-evidence-manifest.json for an immutable deployment. The same bundle includes SHA256SUMS, the demo report, benchmark JSON, workload JSON, status snapshots, hot-key output, and the privacy-safe audit.

Published release identity:

• Commit: 4ba2c1c5c9a1c89073ba47d90c83f98441dfe9a1
• Multi-architecture image: ghcr.io/slizendb/slizen@sha256:4006733aa64b6f55f25855f48a026d7b488ed44b5ad82d1a52ef5968d08daece
• GitHub Release and checksummed evidence
• Release workflow
• 100,000-key extended validation

Evidence contract

The release gate runs uniform, 80/20-like, 99/1-like, and moving-flash scenarios with 1,000 keys, concurrency 32, and 10 seconds per phase. All scenarios must have zero failures and zero value mismatches. The stable 99/1 scenario must additionally show real cache hits and positive measured origin GET reduction. There is deliberately no universal latency or capacity threshold on a shared runner.

The image-bound v0.2.1 run completed all four scenarios with zero request failures and zero value or final-validation mismatches. Its synthetic 99/1 scenario measured 88.734% fewer origin GETs and a 65.736% cache-hit ratio; proxy p99 was 2.856 ms versus 1.777 ms direct, so this is evidence of upstream-load reduction for that run, not a speed claim. A separate 100,000-key validation also completed all four scenarios without failures or mismatches; its raw JSON and five-run high-cardinality benchmark output are attached to the release.

The v0.2.0 release's earlier 100-key synthetic 99/1 run measured 91.376% fewer origin GETs per successful read, while proxy p99 was higher than direct p99. It remains evidence for that one run, not a claim that Slizen is universally faster. v0.2.1 publishes a new, image-bound evidence bundle rather than reusing that result as its own.

Known limitations

• Slizen remains single-node, is not a durable database, and is not a source of truth.
• Direct origin writes can remain stale until local TTL expiration. Server-assisted invalidation remains the v0.3 safety milestone.
• Redis compatibility is intentionally limited, and the admin API has no built-in authentication.
• redcon reads one complete RESP command before Slizen applies byte and argument limits. These settings bound dispatch and upstream work, not parser allocation; upstream response sizes are not bounded by them.
• Long-running soak, 100,000-key churn, and workload-specific capacity validation remain required before serious deployment.

Slizen v0.2.0 — Safe staging and workload evidence

Slizen v0.2.0 — Safe staging and workload evidence

Slizen v0.2.0 is a single-node developer preview focused on letting a team evaluate hot-key pressure safely before enabling local caching.

What is new

• Static, bounded per-prefix deny, observe, and cache policies.
• /v1/audit and slizenctl audit with the versioned slizen.audit.v1 JSON schema.
• Stable recommendation reason codes without Redis values or policy prefixes; HMAC key identifiers remain the default.
• Uniform, 80/20-like, 99/1-like, and moving-flash workload scenarios with p50/p95/p99, cache hit ratio, origin GET reduction, and runtime versions.
• An observe-first Kubernetes sidecar example and Helm chart without an Operator.
• A staging guide with compatibility checks, explicit allowed prefixes, before/after evidence, rollback triggers, and a minutes-scale endpoint rollback.
• Bounded graceful proxy drain and stale-refill protection for writes that pass through Slizen.
• Atomic hotness audit snapshots, bounded top-K selection, explicit telemetry-completeness metadata, and prompt cache invalidation when tracking evicts a hot key.
• Normal-response write deadlines so non-reading clients cannot pin proxy response flushes indefinitely.

Upgrade notes

• Existing configurations without [[cache.policies]] preserve the global mode behavior.
• A cache policy requires explicit max_item_bytes and max_local_ttl values that do not exceed global cache limits.
• deny is a cache/telemetry decision, not an ACL: Redis commands are still forwarded according to the compatibility contract.
• Keys matched by deny are deliberately absent from audit output because they bypass hotness tracking.
• The default Kubernetes examples use observe mode and keep the unauthenticated admin listener on loopback.
• hotness.max_tracked_keys is capped at 100,000. Keys longer than 1,024 bytes are forwarded but excluded from hotness tracking and local caching.

Verify locally

make check
make validate-k8s
make demo-up
make smoke
make demo-report
cat ./tmp/demo-report.md
make demo-down

Known limitations

• Slizen remains single-node and is not a source of truth.
• Local cache and hotness state are disposable and may be lost on restart.
• observe mode forwards reads and collects telemetry but does not serve local values or reduce origin GET load.
• Direct origin writes may remain stale until local TTL expiration. Redis/Valkey-assisted invalidation is the v0.3 safety milestone.
• Redis command compatibility remains intentionally limited.
• The admin API has no built-in authentication.
• Helm deploys a standalone proxy; sidecar injection remains the application's deployment responsibility.
• No mesh, Operator, hosted control plane, SSO/RBAC, or billing is included.
• This is still a developer preview, not a production-readiness claim.

Next milestone

v0.3 focuses on fail-safe Redis/Valkey-assisted invalidation for explicitly allowed prefixes. Mesh and fleet management remain demand-gated hypotheses.

Slizen v0.1.0 — Hot-key autopilot preview for Redis and Valkey

Slizen v0.1.0 — Hot-key autopilot preview for Redis and Valkey

Slizen v0.1.0 is a developer preview of a single-node adaptive cache proxy for Redis and Valkey read-heavy workloads.

What works

• Redis-compatible RESP proxy for a documented v0.1 command subset.
• cache mode with hot-key detection, bounded local cache, request coalescing, and write-driven invalidation.
• observe mode for safe telemetry without local cache hits or value storage.
• Admin API with /healthz, /readyz, /v1/status, /v1/hotkeys, /v1/cache, and Prometheus /metrics.
• HMAC key identifiers in hot-key output by default.
• Docker Compose demo with Valkey.
• slizenctl benchmark hotkey and make demo-report for reproducible local demo evidence.
• CI coverage for Go tests, race tests, real Valkey integration tests, Docker Compose smoke, and benchmark/demo-report artifacts.

Quick start

git clone https://github.com/gazakov/slizen.git
cd slizen
make demo-up
make demo
curl http://127.0.0.1:9090/v1/status
make demo-down

Demo

make demo-up
make demo
make demo-down

The demo starts Valkey and Slizen, waits for readiness, writes and reads a test key through the Slizen RESP proxy, runs a short hot-key load, and prints status/hot-key evidence.

Benchmark

make demo-up
make benchmark
make demo-report
cat ./tmp/demo-report.md
make demo-down

The benchmark compares direct origin GETs with Slizen cold and hot reads. It reports cache hit ratio and upstream GET reduction from real /v1/status counters. It is local demo evidence, not a scientific production benchmark.

Safety model

• Redis or Valkey remains the source of truth.
• Slizen cache and hotness state are disposable.
• Writes are safest when they pass through Slizen because accepted writes invalidate local cache entries.
• Direct upstream writes may remain stale through Slizen until local TTL expiration.
• Keep the admin API private. v0.1 has no built-in admin authentication.
• Slizen should not log values, authentication data, or raw Redis keys in metrics/logs.

Known limitations

• Developer preview; not production-ready.
• Single-node only.
• Limited Redis command compatibility.
• No mesh, gossip, Redis Cluster, Pub/Sub, transactions, blocking commands, RESP3, Kubernetes integration, or built-in auth.
• Local benchmark results depend on machine, Docker, Redis/Valkey, and workload shape.
• observe mode measures heat but does not reduce origin load.

What is next

• Keep tightening compatibility tests and documentation.
• Add more benchmark workloads beyond one fixed hot key.
• Add per-prefix cache policy.
• Research RESP3 and server-assisted invalidation.
• Consider static multi-node membership only after the single-node contract is stable.