Skip to main content
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.