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:

Opcjonalne:

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:

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