Dedicated Discover Redis preparation

A separate discovery-redis service is deployed in the existing Railway production environment. The app is not connected to it and Discover flags remain off. The existing shared Redis is unchanged. This uses the existing Railway account and its metered resources; no vendor subscription was opened.

The reproducible Docker context is ops/discovery-redis. The deployed files were hashed and checked against those repository files. Railway reports one vCPU and 1,000,000,000 bytes of container memory. Live Redis configuration checks confirmed Redis's 536,870,912-byte limit, noeviction, password authentication/protected mode, and no RDB/AOF persistence. Cursor state is temporary; durable history and events remain in the databases.

The service is healthy on private networking. Its private REDIS_URL is stored only in its own Railway variables, with no application variable or deployment change. Temporary public TCP proxies used for the local checks were removed. There is no permanent public proxy.

What passed

The real Redis/session functional probe passed nine checks, including richer personalization snapshots. Its largest body was 1,143,660 bytes and measured namespaced memory before cleanup was 1,655,800 bytes. All 53 owned keys were removed and absence verified by the probe.

A separate temporary Node 22 service then exercised the same actual session, pagination and Redis Lua implementation through Railway's private network. Its fixed workload was sixteen synthetic actors, 1,000 rich v2 cards, two Redis connections, up to 32 in-flight page calls, at most 500 requests and a 30-second dispatch limit. Planned and sampled namespaced memory were capped at 32 MiB. The load-generator container was also limited to one vCPU and 1 GB RAM.

• 500/500 requests succeeded, with no unexpected errors or transport errors.
• All 180 deliberate cursor-replay pairs matched.
• Sixteen visits were admitted. Admission limits rejected 124 new allocations; all 124 found a matching existing visit. No page request surfaced an admission error, and 108 fresh requests reused the same visit as that actor's prior page.
• Sampled peak owned-key memory was 19,933,317 bytes. This is not process RSS, allocator reserve or a continuous peak measurement.
• The run lasted 21.325 seconds of traffic, about 23.447 attempts/second. It removed all 49 surviving owned keys and verified cleanup.

Instrumented request kind	Samples	p50	p95	p99
All	500	937.162 ms	1,986.512 ms	3,180.623 ms
Fresh	140	1,269.294 ms	3,072.421 ms	3,338.296 ms
Cursor/replay	360	786.451 ms	1,810.054 ms	1,942.982 ms

These timings include the load generator's full decoded-fixture assertions and serialization on one CPU. They do not measure the public HTTP endpoint, database queries, ranking, browser rendering or production latency percentiles. Error-free completion is not a claim that these tail latencies are an acceptable reader experience or that sixteen synthetic actors establish a production capacity cap. The run transferred 552,678,770 serialized read bytes and 520,035,159 write bytes; full-state serialization remains a scaling cost to distinguish from test overhead.

The earlier paired codec tests already compared raw and compact writes over eighteen runs. They established large memory/wire savings without a demonstrated latency benefit. The current full-traversal byte sizes reproduce those results: 1,245,766 bytes raw versus 380,678 compact. Raw remains the default. Do not repeat that completed comparison or enable compact merely because this new diagnostic has slow tails; production profiling and the reader-first migration/rollback rules still apply.

Preserved failures and corrections

The initial local capacity run failed, and its controller mistakenly discarded the child script's sanitized failure report. A corrected controller preserved the same bounded workload's diagnostic result: zero page attempts, zero fixture keys and a failure before traffic. A read-only Redis clock measurement then showed the Windows host 21,337–21,355 ms ahead of Redis, beyond the existing five-second guard. The guard was retained and the host clock was not changed. The service was independently checked empty; each temporary proxy was removed. An attempted read-only Railway SSH diagnostic failed and was not used as evidence.

The first cloud container also stopped before any connection: the bundled test omitted its synthetic JSON fixture. The corrected container preserved the original relative file layout and exact fixture bytes. Local import/guard and full 1,000-card preflight checks passed before the second deployment. Neither the tested application logic nor the 16-actor/500-request workload changed. Both temporary cloud services were deleted and independently verified absent across the project's environments. The long-lived dedicated Redis remains.

Release boundary

This completes dedicated Redis provisioning and bounded storage verification. It does not activate the feed or select production admission limits. Match limits to actual arrival/concurrency and payload distribution, then verify full-origin production topology and rollback. The production ClickPipe is still Running with 17 mappings, excluding discovery_events and discovery_erased_actors; actual CDC/archive/erasure receipts remain required before analytics readiness. The experimental content ranker remains unpromoted after its failed quality evidence.

Identity and retained receipts

• Application/probe source: fc5598a0b5994530cfe1a6d30b6f2d86660a64a1.
• Redis service: 699ec38f-3313-4f0a-b905-d4d0d4e3cddb.
• Redis deployment: 092998ff-704a-424b-bac3-5aac71696a77.
• Production environment: 892e044a-9a0c-4e9e-80c0-b28db11ae6fe.
• Corrected cloud bundle manifest: 8364575fb851bddc7622e02281a48b6d35d054c5c7bef9d146975cd222fc3109.
• Successful cloud result: 91b61662daeb16a5f84c848906f3b6f95cc936b3b76bfeddcef51688d50736b8.
• Final independent resource audit: 6a3863a6143153b60289b4e864dc527e385f7ee9f1bd8726e726688214f3eb17.

Ignored controller receipts retain failures, runtime/configuration checks, exact source/bundle hashes, memory/latency samples and cleanup results. No secrets, connection strings, real account records or story content enter this report.