Data Flow

The TV module is purely read-side. This page shows where the data it serves comes from, what tables hold it, and how each piece gets refreshed.

End-to-end pipeline

Sources

Resolution → table routing

Given a TV resolution string, the service picks one of three paths:

Reference: service.go → GetHistory.

The same flow runs for every kind. After resolve() identifies the ticker as kindStock, kindIndex, or kindSubIndex, the resolution switch picks the same-shape helper from the right table family (nepse_price_history vs. nepse_index_history vs. nepse_sub_index_history; nepse_intraday_prices vs. nepse_intraday_indices vs. nepse_intraday_sub_indices). The retention-window check, nextTime hint, and OHLCV marshalling are shared.

Symbol lookup flow

/symbols is the only TV endpoint backed by a persistent Redis cache. The full lookup:

• Cache TTL: 5 minutes (cache.TTLNepseTVSymbol())
• Key: nepse:tv:symbol:<UPPER_SYMBOL>
• Redis unavailability is non-fatal: a cache read error logs a warning and falls through to the DB; a cache write failure logs a warning but still returns the resolved symbol.

Search flow

/search goes straight to Postgres — no Redis caching because queries are highly variable (every keystroke from the frontend).

The SQL prefix-boost makes NAB return NABBC, NABIL, NABILD2089, NABILD87 (symbol-prefix matches) before name-substring matches like KDBY (which contains "nab" inside Dhanabriddhi Yojana). Typing ^ alone surfaces every index and sub-index; typing ^NEP returns ^NEPSE; typing BANK returns ^BANKING, ^DEVBANK, and any company ticker containing BANK.

-- Postgres forbids expression-based ORDER BY on a bare UNION, so the three
-- branches are wrapped in a subquery. The outer ORDER BY then runs CASE
-- against the merged column set.
SELECT tv_symbol, description, kind
FROM (
    (
        SELECT symbol AS tv_symbol, name AS description, 'stock'::text AS kind
        FROM nepse_companies
        WHERE status = 'A'
          AND (symbol ILIKE '%' || @search || '%' OR name ILIKE '%' || @search || '%')
    ) UNION ALL (
        SELECT '^' || tv_symbol AS tv_symbol, index_name AS description, 'index'::text AS kind
        FROM nepse_indices
        WHERE tv_symbol ILIKE '%' || @search || '%'
           OR index_name ILIKE '%' || @search || '%'
           OR ('^' || tv_symbol) ILIKE '%' || @search || '%'
    ) UNION ALL (
        SELECT '^' || tv_symbol AS tv_symbol, name AS description, 'index'::text AS kind
        FROM nepse_sub_indices
        WHERE tv_symbol ILIKE '%' || @search || '%'
           OR name ILIKE '%' || @search || '%'
           OR ('^' || tv_symbol) ILIKE '%' || @search || '%'
    )
) AS merged
ORDER BY
  CASE WHEN tv_symbol ILIKE @search || '%' THEN 0 ELSE 1 END,
  tv_symbol
LIMIT @lim;

Where live ticks fit in (future)

/history ends where the Postgres database ends. Live bars currently forming during market hours are only visible after the poller's next flush — typically within a minute.

For v1, the frontend uses TV's default UDFCompatibleDatafeed, which polls /history every ~10s for the current bar. Bars update at poll cadence — perceptually fine for OHLC candles, and nginx caching plus the Go app's rate limiter absorb the traffic easily at a few hundred concurrent chart viewers.

The parked Phase 6 plan (see docs/TRADINGVIEW_UDF_PHASE6.md) adds a WebSocket gateway for tick-level latency. Decision: deferred until measured pain justifies the build — laggy charts, polling bottleneck on /history, or >500 concurrent chart viewers. See Integration for the frontend seam when it's time to wire it up.

Freshness guarantees