# 3700X jako drugi bare metal dla Drift perps

Ten dokument opisuje sensowną rolę drugiego hosta:

- `AMD Ryzen 7 3700X`
- `128 GB RAM`
- `2 x 1 TB NVMe`
- `1 Gbps`

W tym układzie zakładamy, że:

- host `9950X` robi tylko `Agave + Yellowstone Geyser`,
- host `3700X` robi `consumer + processing + lekka/umiarkowana baza`,
- komunikacja między hostami idzie po prywatnej sieci (`private VLAN` albo później `wg0`).

## Cel

Rozdzielić role:

- `9950X`: ingest danych z Solany, bez ciężkiej obróbki
- `3700X`: odbiór streamu, dekodowanie Drift, budowa DLOB, zapis pochodnych danych, API i worker-y

To zmniejsza ryzyko, że:

- baza danych,
- parser,
- albo batch/worker

zwiększą lag walidatora.

## Co uruchamiać na 3700X

Tak:

- Yellowstone gRPC consumer
- parser Drift
- cache stanu w RAM
- worker-y realtime
- Redis / NATS / lekka kolejka
- Postgres o umiarkowanej skali
- read-only API / query layer
- monitoring

Nie:

- `agave-validator`
- ciężkie historyczne archiwum raw streamu
- duży ClickHouse na start
- wszystko naraz bez limitów retencji

## Układ usług

Przepływ:

1. `9950X` uruchamia `Agave + Geyser plugin`
2. `3700X` łączy się po prywatnym adresie do `gRPC`
3. consumer odbiera tylko potrzebny scope Drift
4. parser buduje lokalny stan
5. do DB trafiają tylko dane pochodne i potrzebne eventy

Model:

- host A = producer
- host B = consumer + processing

## Dyski

Najprostszy podział:

- `nvme0`:
  - system
  - Docker
  - binarki
  - cache buildów
- `nvme1`:
  - dane consumera
  - Postgres
  - logi aplikacyjne
  - kolejki / spool

Filesystem:

- `ext4` na obu dyskach

## Minimalny scope Yellowstone pod Drift perps

Na start nie streamuj całej Solany. Dla Drift perps minimalny sensowny zakres to:

- `slots`
- `transactions` tylko dla programu Drift
- `accounts` dla kont Drift potrzebnych do stanu rynku i userów

## Konta i strumienie

Na start streamuj:

- `State`
- `PerpMarketAccount` dla wybranych rynków
- `SpotMarketAccount` potrzebne do collateral / quote
- `UserAccount`

Powód:

- Drift trzyma zlecenia i pozycje w `UserAccount`
- lokalny `DLOB` buduje się właśnie z `UserAccount`
- `PerpMarketAccount` daje stan rynku
- `SpotMarketAccount` jest potrzebny dla cross-margin

## Filtry v1

Najrozsądniejsza wersja startowa:

- `slots`: włączone
- `transactions`:
  - `account_include = [Drift Program ID]`
  - bez vote tx
- `accounts`:
  - exact accounts dla `State` i marketów
  - `UserAccount` dla programu Drift

Jeśli interesują Cię tylko wybrane rynki, np. `SOL-PERP`, `BTC-PERP`, `ETH-PERP`, to:

- odbierasz `UserAccount`,
- po dekodzie odrzucasz userów bez pozycji i bez orderów na tych rynkach

To jest bezpieczniejsze operacyjnie niż próba zbyt agresywnego filtrowania przed dekodem.

## Co liczyć po stronie consumera

W RAM trzymaj:

- cache `UserAccount`
- cache `PerpMarketAccount`
- cache `SpotMarketAccount`
- ostatni slot

Z tego licz:

- lokalny `DLOB`
- best bid / ask
- depth
- zmiany pozycji
- fills
- liquidations
- funding / mark / oracle impact

Do DB zapisuj:

- eventy biznesowe
- snapshoty pochodne
- agregaty

Nie zapisuj na start całego raw streamu 1:1.

## Co daje taki układ

- mniejszy wpływ processingu na lag walidatora
- bezpieczny transport po prywatnej sieci
- prostsza diagnostyka
- możliwość restartu parsera bez ruszania noda
- łatwiejsze skalowanie w przyszłości

## Ograniczenia 3700X

Ten host jest dobry jako:

- consumer node
- processing node
- umiarkowana DB

To nie jest idealny host pod:

- bardzo ciężki ClickHouse
- duże historyczne archiwum
- wiele ciężkich pipeline'ów naraz

Najbardziej ograniczą Cię:

- `1 Gbps`
- pojemność `2 x 1 TB`
- RAM przy większej retencji i większej liczbie workerów

## Rekomendacja startowa

Na `3700X` uruchom:

- Yellowstone consumer
- Drift parser
- Redis
- Postgres
- lekkie API

Na `9950X` zostaw tylko:

- `Agave`
- `Geyser`

Najpierw uruchom zakres dla 2-3 rynków perp i dopiero potem rozszerzaj.

## Powiązane dokumenty

- `doc/rpc/software-placement.md`
- `doc/rpc/geyser-dlob.md`
- `doc/dlob-services.md`