> ## Documentation Index
> Fetch the complete documentation index at: https://docs.openkol.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Storage and Caching

> How analysis snapshots stay fast and reproducible.

OpenKol needs to be both **fast** and **repeatable**:

* fast enough to feel instant
* repeatable enough to be trusted and shared

That’s why the system separates **storage** (truth) from **caching** (speed).

***

## Storage (Postgres)

OpenKol stores:

* normalized posts (author, timestamp, engagement, extracted symbols)
* analysis snapshots (scores, medal, resolved token/pair, window metadata)
* derived aggregates used for KOL profiles and leaderboards

Storage is the source of truth for:

* permalinks
* history
* profile rollups
* re-opening an analysis without recomputing everything

***

## Caching (Redis)

Redis is used to cache high-cost lookups and frequently requested artifacts, including:

* post details and normalized metadata
* analysis snapshots for fast page loads
* token pair and liquidity lookups
* candle data for common windows and resolutions

Caching reduces:

* repeated external provider calls
* page latency spikes
* load during traffic bursts (e.g., viral share cards)

***

## Local history (client)

The client keeps a lightweight analysis history in LocalStorage to:

* quickly reopen recent analyses
* avoid unnecessary refetching during navigation

Local history is convenience only — the server snapshot remains the canonical source for share links.

***

## Why it matters

* **Persistent storage** gives auditability and stable permalinks.
* **Caching** keeps the experience fast and lowers external dependency load.
* Together, they help OpenKol stay reliable even when usage spikes or upstream providers rate-limit.