# mevnode-bot overlay

To jest docelowy overlay dla runtime `mevnode_bot`.

Zakres:

- `postgres`
- `hasura`
- `trade-frontend` (`NodePort 30081`)
- `dlob-redis`
- `dlob-publisher-hot`
- `dlob-publisher-all`
- `dlob-hot-redis-to-postgres-raw-writer`
- `dlob-hot-postgres-to-postgres-derived-writer`
- `dlob-all-redis-to-postgres-derived-writer`

Założenia runtime:

- `mevnode_sol` wystawia po `wg0`:
  - `RPC`: `http://10.91.0.1:8899`
  - `WS`: `ws://10.91.0.1:8900`
  - `Yellowstone`: `http://10.91.0.1:10000`
- `mevnode_bot` uruchamia tylko warstwę aplikacyjną.
- `trade-frontend` jest wystawiany przez `NodePort 30081`.
- Namespace pozostaje `trade-staging`.

Topologia DLOB w tym overlayu:

- `dlob-publisher-hot` to hot-path na wybrane markety (`PERP_MARKETS_TO_LOAD=0,20,72`, czyli `SOL-PERP`, `JTO-PERP`, `ADA-PERP`) i prefix Redis `DLOB_HOT` (`dlob-hot:`).
- `dlob-publisher-all` to szeroki feed do wszystkich marketów na prefix Redis `DLOB_ALL` (`dlob-all:`).
- `dlob-hot-redis-to-postgres-raw-writer` to schema-first writer: czyta `dlob-hot:` z Redis i zapisuje kanoniczny raw DLOB do PostgreSQL (`dlob_hot_snapshot_latest`, `dlob_hot_snapshot_ts`).
- `dlob-hot-postgres-to-postgres-derived-writer` czyta raw hot z PostgreSQL i buduje normalized layer (`dlob_hot_derived_latest`, `dlob_hot_derived_ts`).
- `LIVE` na `k3s`: sciezka `hot` jest juz aktywna jako `Redis -> raw PG -> derived PG`.
- `dlob-publisher-all` celowo nie ma patcha persistent store, żeby nie dublowac zapisow do Postgresa.
- `dlob-all-redis-to-postgres-derived-writer` zapisuje dla `all` tylko warstwe pochodna do PostgreSQL; bez `raw_ts`, zeby nie zjadac dysku w kilka dni.
- `LIVE` na `k3s`: sciezka `all` jest aktywna jako `Redis -> derived PG`.
- `all` zapisuje pelne `derived_ts` dla wszystkich marketow z `dlob-all:*`, bez samplingu i bez shortlisty marketow.

Planowany zakres zapisu dla `all`:

- tozsamosc i czas: `source`, `market_type`, `market_index`, `market_name`, `is_indicative`, `event_ts/ts_ms`, `slot`, `market_slot`
- cena i mikrostruktura: `mark_price`, `oracle_price`, `best_bid_price`, `best_ask_price`, `mid_price`, `spread_quote`, `spread_bps`
- plynnosc: `depth_levels`, `bid_levels`, `ask_levels`, `top_bid_size`, `top_ask_size`, `top_bid_notional`, `top_ask_notional`, `depth_bid_base`, `depth_ask_base`, `depth_bid_quote`, `depth_ask_quote`, `imbalance`
- drabinka do modelu/UI: `bids_norm`, `asks_norm` jako top `10` leveli z polami `price`, `sizeBase`, `notional`, `sources`
- kontrola jakosci i dedupe: `raw_payload_hash`, `updated_at` / `inserted_at`
- celowo pomijamy: pelny `raw payload`, `raw latest`, `raw ts`, `L3`, `best_makers`

Polityka `hot` vs `all`:

- `hot` i `all` rozniamy po roli operacyjnej, nie po samym mechanizmie subskrypcji.
- `hot` = `dlob-publisher-hot`: subset marketow, najnizsza latencja, najwyzszy priorytet operacyjny.
- `all` = `dlob-publisher-all`: pelne pokrycie marketow, feed do coverage/read-side/analityki, nizszy priorytet operacyjny niz `hot`.
- `USE_ORDER_SUBSCRIBER=true` moze byc wlaczone na obu publisherach; to nie definiuje roli `hot` vs `all`.
- `hot` powinien byc broniony jako pierwszy przy problemach z CPU/RAM/RPC i nie powinien byc degradowany przed `all`.
- Jesli trzeba ograniczac load albo robic fallback, najpierw degradujemy `all`, dopiero potem `hot`.

Zalecana polityka runtime:

- `hot`: utrzymywac `OrderSubscriber + gRPC` jako sciezke docelowa.
- `all`: domyslnie tez `OrderSubscriber + gRPC`, ale to pierwszy kandydat do przejscia na slabszy tryb przy presji zasobow.
- Kolejnosc degradacji dla `all`: `gRPC -> websocket -> polling`.
- Wylaczenie `USE_ORDER_SUBSCRIBER` traktowac jako tryb awaryjny/testowy, nie jako stan docelowy.

Wymagane sekrety:

- `trade-postgres`
- `trade-hasura`
- `trade-frontend-tokens`
- `trade-dlob-rpc`

Opcjonalne:

- `gitea-registry` nie jest tu wymagane, bo overlay czyści `imagePullSecrets`.

Uwagi:

- Overlay zastępuje lokalny `_tmp/bot-rx-stack`.
- `trade-deploy/kustomize/overlays/mevnode-bot` jest teraz źródłem prawdy dla runtime `mevnode_bot`.
- Ten overlay nadal korzysta z plików z `../../base` w `configMapGenerator`, więc przy lokalnym `kustomize` może być potrzebne:

```bash
sudo k3s kubectl kustomize trade-deploy/kustomize/overlays/mevnode-bot --load-restrictor LoadRestrictionsNone | sudo k3s kubectl apply -f -
```