Caching — Draft
Draft Redis is not deployed. The running web helpers use cache: no-store; requestCache wraps React’s server per-request memoizer to deduplicate identical reads during one render. There is no shared API product-cache provider.
| Data | Running behavior | Deferred target |
|---|---|---|
| Product lists and details | No-store fetch; per-request deduplication where wrapped | Redis lists 1 h and detail 4 h, invalidated by editor saves |
| Comparisons | Anonymous live API calculation | 15-minute shared snapshots invalidated by product changes |
| Editorial content | Dynamic no-store fetch | Timed/on-demand caching after deployment constraints permit |
| Document metadata | No implemented production document repository | 24-hour cache with upload invalidation |
| Profiles | Feature absent | No shared cache for private data |
The historical Redis trigger was p95 PostgreSQL product-query latency over 100 ms or over 200 peak concurrent sessions. These are proposed adoption criteria, not monitored automated gates.
Accounts — Draft
Draft Clerk, personal profiles, saved comparisons, alerts and /mi-cuenta/** are deferred. The schema preserves user_profiles, saved_comparisons, user_alerts and consent_records; the corresponding HTTP routes return authentication stubs.
The target is hosted Clerk login and server-validated sessions, lazy profile provisioning, preference-based sorting, currency and vertical preferences, notifications and export/erasure workflows. None is part of the running public flow. Future account work needs explicit PII review and a new implementation plan; the existing lead controls do not implement account compliance.
Documents — Draft
Draft Document upload, authenticated downloads and version management are not operational. static_documents and document_versions remain in the schema, while the production repository does not implement their reads.
The target covers rate sheets, pension prospectuses, regulatory disclosures, product terms and calculator methodology. A proposed initial Railway volume at /data/documents would retain originals with metadata, effective dates, access levels and a current-version pointer. Authenticated redirects to signed downloads (proposed 15-minute lifetime), upload validation, backups and access checks all require implementation.
The later R2 migration proposal was triggered by storage above 1 GB or more than 500 daily downloads over seven days. Its proposed sequence was provision storage, copy files and update storage metadata, switch signing, then retire the volume after 30 days of verified parallel operation. No migration script or R2 Terraform exists; Terraform currently manages GitHub only. Future storage provisioning requires a separate approved change.