feat(visualizer): add runtime architecture diagram
This commit is contained in:
344
doc/data-ingest-strategy.md
Normal file
344
doc/data-ingest-strategy.md
Normal file
@@ -0,0 +1,344 @@
|
||||
# Data ingest strategy
|
||||
|
||||
## Cel
|
||||
|
||||
Zachowac niski latency dla logiki tradingowej i read-side, ale rownoczesnie miec trwala persystencje danych do UI, replayu, debugowania i analityki.
|
||||
|
||||
Nie robimy modelu `DB-first` jako jedynej sciezki przetwarzania.
|
||||
|
||||
## Rekomendowany model
|
||||
|
||||
Stosujemy `dual-path`:
|
||||
|
||||
1. `hot path`
|
||||
`Yellowstone gRPC / Agave RPC -> consumer -> Redis / internal state -> strategy / read-side`
|
||||
|
||||
2. `durable path`
|
||||
`ten sam consumer -> Postgres -> UI / Hasura / replay / debug`
|
||||
|
||||
Opcjonalnie pozniej:
|
||||
|
||||
3. `history / analytics path`
|
||||
`consumer lub batch exporter -> ClickHouse`
|
||||
|
||||
## Dlaczego nie DB-first
|
||||
|
||||
Model:
|
||||
|
||||
`gRPC / RPC -> DB -> dopiero potem przetwarzanie`
|
||||
|
||||
nie jest dobry jako glowna sciezka, bo:
|
||||
|
||||
- dodaje latency do kazdego eventu
|
||||
- uzaleznia ingest od kondycji bazy
|
||||
- pogarsza odpornosc calego pipeline
|
||||
- zwieksza write amplification przy duzym wolumenie zdarzen
|
||||
- utrudnia low-latency strategie i read-side
|
||||
|
||||
DB ma byc miejscem persystencji i read modelu, nie bramka przed logika runtime.
|
||||
|
||||
## Rola Yellowstone gRPC
|
||||
|
||||
Yellowstone ma byc glownym zrodlem `live feed`:
|
||||
|
||||
- account updates
|
||||
- tx updates
|
||||
- slot updates
|
||||
- program updates
|
||||
|
||||
Sciezka:
|
||||
|
||||
`Yellowstone -> consumer -> hot state`
|
||||
|
||||
oraz rownolegle:
|
||||
|
||||
`Yellowstone -> normalization / persistence -> Postgres`
|
||||
|
||||
Yellowstone nie powinien byc uzalezniony od tego, czy Postgres aktualnie pisze szybko.
|
||||
|
||||
## Rola Agave RPC
|
||||
|
||||
RPC nie jest naturalnym feedem eventowym.
|
||||
|
||||
RPC powinno sluzyc glownie do:
|
||||
|
||||
- point reads
|
||||
- bootstrapu klienta
|
||||
- recovery
|
||||
- getAccountInfo / getMultipleAccounts
|
||||
- getHealth / getSlot
|
||||
- write path dla tx, jesli nie idziemy przez TPU/Jito
|
||||
|
||||
RPC nie powinno byc traktowane jak glowny event stream do zrzucania wszystkiego do DB.
|
||||
|
||||
## Rola Redis
|
||||
|
||||
Redis powinien byc `hot state layer`:
|
||||
|
||||
- szybki stan DLOB
|
||||
- cache
|
||||
- fanout wewnetrzny
|
||||
- ewentualnie stream / queue dla workerow
|
||||
|
||||
To jest warstwa pod:
|
||||
|
||||
- strategy engine
|
||||
- orderbook read-side
|
||||
- szybkie projekcje
|
||||
|
||||
Nie trzymamy tam historii jako source of truth.
|
||||
|
||||
## Rola Postgres
|
||||
|
||||
Postgres powinien byc `durable read model`:
|
||||
|
||||
- dane dla UI
|
||||
- dane dla Hasury
|
||||
- znormalizowane ticki
|
||||
- pochodne tabele DLOB
|
||||
- stan aplikacji
|
||||
- konfiguracja
|
||||
- historia operacyjna
|
||||
|
||||
Postgres jest dobry do:
|
||||
|
||||
- frontend
|
||||
- dashboard
|
||||
- replay lekkiego zakresu
|
||||
- audyt aplikacyjny
|
||||
|
||||
## Kiedy ClickHouse
|
||||
|
||||
ClickHouse dodajemy dopiero, gdy:
|
||||
|
||||
- wolumen raw feedu bedzie duzy
|
||||
- potrzebna bedzie ciezsza analityka historyczna
|
||||
- bedziemy chcieli trzymac dluzsza historie eventow i tx
|
||||
|
||||
Na obecnym etapie nie jest konieczny do uruchomienia runtime.
|
||||
|
||||
## Docelowy przeplyw
|
||||
|
||||
```text
|
||||
mevnode_sol
|
||||
Agave RPC
|
||||
Yellowstone gRPC
|
||||
|
|
||||
v
|
||||
mevnode_bot
|
||||
consumer
|
||||
|\
|
||||
| +--> Redis -> DLOB/read-side -> strategy/workers
|
||||
|
|
||||
+----> Postgres -> Hasura/API -> frontend
|
||||
```
|
||||
|
||||
## Zasada architektoniczna
|
||||
|
||||
- `gRPC / RPC` dostarcza dane do runtime
|
||||
- `Redis` utrzymuje szybki stan operacyjny
|
||||
- `Postgres` utrzymuje trwaly stan i read model
|
||||
- `frontend` i `Hasura` czytaja z Postgresa
|
||||
- `strategy` i `workers` nie czekaja na zapis do DB, aby przetwarzac dane
|
||||
|
||||
## Rekomendacja dla projektu
|
||||
|
||||
Na teraz:
|
||||
|
||||
1. `Yellowstone -> consumer -> Redis`
|
||||
2. `consumer -> Postgres`
|
||||
3. `Hasura / API / UI <- Postgres`
|
||||
4. `strategy / read-side <- Redis`
|
||||
5. `RPC` zostawic do bootstrapu, point reads i write path
|
||||
|
||||
To daje najlepszy kompromis:
|
||||
|
||||
- niski latency
|
||||
- odpornosc runtime
|
||||
- sensowna persystencja
|
||||
- dobra baza pod UI i replay
|
||||
|
||||
## Ocena obecnego ukladu na k3s
|
||||
|
||||
Obecny runtime na `mevnode_bot / trade-staging` jest tylko czesciowo zgodny z docelowym modelem.
|
||||
|
||||
### Co jest zgodne
|
||||
|
||||
- `postgres` jest postawiony jako `StatefulSet`, wiec nadaje sie na trwały storage
|
||||
- `dlob-redis` jest osobna lekka usluga i pasuje do roli cache / hot state
|
||||
- `hasura` i `trade-api` siedza nad `Postgresem`, co jest poprawne dla durable read modelu
|
||||
- `frontend` korzysta z `API/Hasury`, a nie bezposrednio z `Redis`
|
||||
|
||||
### Co nie jest zgodne
|
||||
|
||||
- `dlob-publisher` i `dlob-server` nie sa zdrowe, wiec hot path nie jest operacyjnie domkniety
|
||||
- `dlob-publisher` jest podpiety do `gRPC`, ale nie jest glownym i pewnym writerem do `Postgresa`
|
||||
- `trade-ingestor` nie ingestuje danych bezposrednio z chain source, tylko polluje dane pochodne z `Hasury`
|
||||
- persistent path jest wiec dzisiaj czesciowo odwrocony:
|
||||
- `derived view -> ingest -> Postgres`
|
||||
- zamiast:
|
||||
- `chain source -> normalize -> Postgres`
|
||||
|
||||
## Plan zmian
|
||||
|
||||
### Cel koncowy
|
||||
|
||||
Chcemy dojsc do ukladu:
|
||||
|
||||
```text
|
||||
Yellowstone gRPC / Agave RPC
|
||||
|
|
||||
v
|
||||
consumer
|
||||
|\
|
||||
| +--> Redis -> hot state / workers / strategy
|
||||
|
|
||||
+----> Postgres -> Hasura / API / frontend / replay
|
||||
```
|
||||
|
||||
### Etap 1. Naprawa hot path
|
||||
|
||||
Najpierw trzeba przywrocic dzialanie:
|
||||
|
||||
- `dlob-publisher`
|
||||
- `dlob-server`
|
||||
|
||||
Bez zdrowego publishera nie ma sensu budowac dalszej warstwy `Redis = hot state`.
|
||||
|
||||
Zakres:
|
||||
|
||||
- ustabilizowac `Agave RPC` i `Yellowstone`
|
||||
- doprowadzic `dlob-publisher` do `Ready`
|
||||
- potwierdzic, ze `Redis` dostaje aktualny stan
|
||||
- doprowadzic `dlob-server` do `Ready`
|
||||
|
||||
### Etap 2. Uczynic publisher glownym consumerem danych chain
|
||||
|
||||
Obecnie `trade-ingestor` korzysta z danych pochodnych z `Hasury`.
|
||||
|
||||
To trzeba zmienic tak, aby glownym miejscem wejscia danych byl komponent konsumujacy:
|
||||
|
||||
- `Yellowstone gRPC`
|
||||
- `Agave RPC`
|
||||
|
||||
Rekomendacja:
|
||||
|
||||
- rozszerzyc `dlob-publisher`
|
||||
- albo wydzielic nowy `market-consumer`
|
||||
|
||||
ale w obu przypadkach komponent ma robic:
|
||||
|
||||
- odczyt live z `Yellowstone`
|
||||
- wymagane point reads z `RPC`
|
||||
- normalizacje danych
|
||||
- jednoczesny zapis do `Redis` i `Postgresa`
|
||||
|
||||
### Etap 3. Ustalic twardy podzial rol Redis / Postgres
|
||||
|
||||
#### Redis
|
||||
|
||||
Do `Redis` trafia tylko to, co potrzebne jako szybki stan runtime:
|
||||
|
||||
- latest DLOB state
|
||||
- latest L2
|
||||
- quick cache dla workerow
|
||||
- fanout do read-side i strategii
|
||||
- dane z TTL lub dane odtwarzalne
|
||||
|
||||
`Redis` nie jest source of truth.
|
||||
|
||||
#### Postgres
|
||||
|
||||
Do `Postgresa` trafia trwaly model danych:
|
||||
|
||||
- znormalizowane ticki
|
||||
- znormalizowane snapshoty rynku
|
||||
- pochodne tabele pod `Hasure`
|
||||
- historia operacyjna
|
||||
- stan aplikacji
|
||||
|
||||
`Postgres` jest source of truth dla aplikacji i UI.
|
||||
|
||||
### Etap 4. Przebudowac worker path
|
||||
|
||||
Docelowy model dla workerow:
|
||||
|
||||
- `Redis in`
|
||||
- `Postgres out`
|
||||
|
||||
To znaczy:
|
||||
|
||||
- workery czytaja szybki stan z `Redis`
|
||||
- licza projekcje
|
||||
- zapisują wynik do `Postgresa`
|
||||
|
||||
Dotyczy to szczegolnie:
|
||||
|
||||
- `dlob-worker`
|
||||
- `dlob-depth-worker`
|
||||
- `dlob-slippage-worker`
|
||||
|
||||
### Etap 5. Wygasic obecny odwrocony ingest
|
||||
|
||||
Obecny `trade-ingestor` zapisuje dane do `Postgresa` na podstawie danych juz pochodnych z `Hasury`.
|
||||
|
||||
To nie powinno byc glowna sciezka ingestu.
|
||||
|
||||
Mozliwe role po zmianie:
|
||||
|
||||
- backfill
|
||||
- sanity check
|
||||
- fallback
|
||||
- testowy importer
|
||||
|
||||
Ale nie:
|
||||
|
||||
- glowny chain ingest
|
||||
|
||||
### Etap 6. Utrwalic read model pod UI
|
||||
|
||||
Po zmianach:
|
||||
|
||||
- `Hasura` czyta tylko z `Postgresa`
|
||||
- `trade-api` czyta tylko z `Postgresa`
|
||||
- `frontend` czyta przez `API/Hasure`
|
||||
|
||||
Frontend nie powinien zalezec od `Redis`.
|
||||
|
||||
### Etap 7. Zostawic RPC w waskiej roli
|
||||
|
||||
`Agave RPC` zostawiamy do:
|
||||
|
||||
- bootstrapu
|
||||
- point reads
|
||||
- recovery
|
||||
- write path dla tx
|
||||
|
||||
Nie robimy z `RPC` glownej magistrali trwałego ingestu.
|
||||
|
||||
## Plan wdrozenia krok po kroku
|
||||
|
||||
1. Naprawic `dlob-publisher` i `dlob-server`.
|
||||
2. Potwierdzic, ze `Redis` jest zasilany poprawnym hot state.
|
||||
3. Rozszerzyc publisher albo dodac nowy consumer tak, aby pisal rownolegle do:
|
||||
- `Redis`
|
||||
- `Postgresa`
|
||||
4. Zdefiniowac schemat tabel normalized data w `Postgresie`.
|
||||
5. Przepiac workery na model:
|
||||
- read z `Redis`
|
||||
- write do `Postgresa`
|
||||
6. Zostawic `Hasure` i `trade-api` jako warstwe odczytowa nad `Postgresem`.
|
||||
7. Zdegradowac `trade-ingestor` z roli glownego ingestu do roli pomocniczej albo go usunac z glownej sciezki.
|
||||
|
||||
## Rekomendacja praktyczna
|
||||
|
||||
Najmniejsza sensowna zmiana to nie budowac od razu nowego systemu od zera, tylko:
|
||||
|
||||
1. naprawic obecny `dlob-publisher`
|
||||
2. dodac mu zapis do `Postgresa`
|
||||
3. stopniowo wyprowadzac `trade-ingestor` z glownego path
|
||||
|
||||
To jest najmniej ryzykowna droga do modelu:
|
||||
|
||||
- `Redis = cache / hot state`
|
||||
- `Postgres = persistent normalized store`
|
||||
245
doc/mevnode-bot-architecture.md
Normal file
245
doc/mevnode-bot-architecture.md
Normal file
@@ -0,0 +1,245 @@
|
||||
# Mevnode Bot Architecture
|
||||
|
||||
## Zasada glowna
|
||||
|
||||
`mevnode_bot` nigdy nie uruchamia warstwy Solana node:
|
||||
|
||||
- bez `agave`
|
||||
- bez `ledger`
|
||||
- bez `yellowstone server`
|
||||
- bez validator stack
|
||||
|
||||
`mevnode_sol` pozostaje jedynym hostem node-level:
|
||||
|
||||
- `agave-validator`
|
||||
- `yellowstone geyser plugin`
|
||||
- `yellowstone gRPC`
|
||||
- plugin metrics
|
||||
- lokalny RPC
|
||||
- opcjonalnie pozniej RPC proxy
|
||||
|
||||
## Schemat `mevnode_bot`
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------+
|
||||
| mevnode_bot |
|
||||
| single-node k3s only |
|
||||
| |
|
||||
| ingress/web |
|
||||
| - frontend |
|
||||
| - api |
|
||||
| |
|
||||
| trading/read |
|
||||
| - yellowstone-consumer |
|
||||
| - market ingest / parser |
|
||||
| - dlob-worker |
|
||||
| |
|
||||
| trading/core |
|
||||
| - strategy-engine |
|
||||
| - risk-manager |
|
||||
| - order-manager |
|
||||
| - tx-router |
|
||||
| |
|
||||
| tx paths |
|
||||
| - tpu client |
|
||||
| - jito client |
|
||||
| - rpc client / later rpc proxy target on mevnode_sol |
|
||||
| |
|
||||
| data |
|
||||
| - postgres |
|
||||
| - redis optional |
|
||||
| - clickhouse later optional |
|
||||
| |
|
||||
| ops |
|
||||
| - prometheus |
|
||||
| - grafana |
|
||||
| - loki optional |
|
||||
| |
|
||||
| platform |
|
||||
| - argo/flux |
|
||||
| - sealed-secrets or sops |
|
||||
| - internal registry access |
|
||||
+--------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Przeplyw danych
|
||||
|
||||
```text
|
||||
Yellowstone on mevnode_sol
|
||||
|
|
||||
v
|
||||
yellowstone-consumer
|
||||
|
|
||||
v
|
||||
parser / ingest / dlob-worker
|
||||
|
|
||||
v
|
||||
strategy-engine
|
||||
|
|
||||
v
|
||||
risk-manager / order-manager
|
||||
|
|
||||
v
|
||||
tx-router
|
||||
| | |
|
||||
v v v
|
||||
TPU Jito RPC
|
||||
```
|
||||
|
||||
## Namespace plan
|
||||
|
||||
- `web`
|
||||
- `trade`
|
||||
- `data`
|
||||
- `ops`
|
||||
- `infra`
|
||||
|
||||
## Kolejnosc wdrozenia
|
||||
|
||||
1. `web`: `frontend`, `api`
|
||||
2. `data`: `postgres`
|
||||
3. `trade`: `yellowstone-consumer`
|
||||
4. `trade`: `strategy-engine`, `tx-router`
|
||||
5. `ops`: `prometheus`, `grafana`
|
||||
|
||||
## Read i write path
|
||||
|
||||
Read path:
|
||||
|
||||
- `mevnode_bot -> wg0 -> mevnode_sol:10000`
|
||||
|
||||
Metrics path:
|
||||
|
||||
- `mevnode_bot -> wg0 -> mevnode_sol:8999`
|
||||
|
||||
Write path pozniej:
|
||||
|
||||
- `mevnode_bot -> TPU/Jito`
|
||||
- albo `mevnode_bot -> RPC proxy -> mevnode_sol:127.0.0.1:8899`
|
||||
|
||||
## Zasada architektoniczna
|
||||
|
||||
- `mevnode_sol` = source of truth dla chain access
|
||||
- `mevnode_bot` = execution and product node
|
||||
|
||||
## K3s object map
|
||||
|
||||
### Namespace `web`
|
||||
|
||||
- `Deployment` `frontend`
|
||||
- `Service` `frontend` typu `ClusterIP`
|
||||
- `Deployment` `api`
|
||||
- `Service` `api` typu `ClusterIP`
|
||||
- `Ingress` `web`
|
||||
|
||||
Przeznaczenie:
|
||||
|
||||
- `frontend` wystawia UI
|
||||
- `api` wystawia backend HTTP
|
||||
- `Ingress` publikuje tylko web entrypoint
|
||||
|
||||
### Namespace `trade`
|
||||
|
||||
- `Deployment` `yellowstone-consumer`
|
||||
- `Deployment` `dlob-worker`
|
||||
- `Deployment` `strategy-engine`
|
||||
- `Deployment` `risk-manager`
|
||||
- `Deployment` `order-manager`
|
||||
- `Deployment` `tx-router`
|
||||
- `Service` `strategy-engine` typu `ClusterIP` jesli inne komponenty maja sie do niego odwolywac
|
||||
- `Service` `tx-router` typu `ClusterIP` tylko jesli potrzebne bedzie sterowanie po HTTP/gRPC
|
||||
|
||||
Przeznaczenie:
|
||||
|
||||
- `yellowstone-consumer` czyta stream z `mevnode_sol`
|
||||
- `dlob-worker` robi ingest i przygotowanie danych
|
||||
- `strategy-engine` podejmuje decyzje
|
||||
- `risk-manager` egzekwuje limity
|
||||
- `order-manager` sklada i nadzoruje lifecycle zlecen
|
||||
- `tx-router` wybiera `TPU`, `Jito` albo `RPC`
|
||||
|
||||
Uwagi:
|
||||
|
||||
- `strategy-engine`, `order-manager` i `tx-router` mozna uruchamiac z `hostNetwork: true`, jesli bedzie potrzeba minimalizacji narzutu sieciowego
|
||||
- `yellowstone-consumer` powinien miec `Secret` z `x-token` i endpointem `10.91.0.1:10000`
|
||||
|
||||
### Namespace `data`
|
||||
|
||||
- `StatefulSet` `postgres`
|
||||
- `Service` `postgres` typu `ClusterIP`
|
||||
- `PersistentVolumeClaim` dla `postgres`
|
||||
- `StatefulSet` `redis` opcjonalnie
|
||||
- `Service` `redis` typu `ClusterIP`
|
||||
- `PersistentVolumeClaim` dla `redis` tylko jesli ma byc trwaly cache
|
||||
- `StatefulSet` `clickhouse` dopiero pozniej
|
||||
- `Service` `clickhouse` typu `ClusterIP`
|
||||
- `PersistentVolumeClaim` dla `clickhouse`
|
||||
|
||||
Przeznaczenie:
|
||||
|
||||
- `postgres` dla stanu systemu, pozycji, filli, konfiguracji i jobow
|
||||
- `redis` dla cache, kolejek, lockow i rate limitu
|
||||
- `clickhouse` dla ciezszej analityki i archiwizacji eventow
|
||||
|
||||
### Namespace `ops`
|
||||
|
||||
- `StatefulSet` `prometheus`
|
||||
- `Service` `prometheus` typu `ClusterIP`
|
||||
- `Deployment` `grafana`
|
||||
- `Service` `grafana` typu `ClusterIP`
|
||||
- `Deployment` `promtail` opcjonalnie
|
||||
- `StatefulSet` albo `Deployment` `loki` opcjonalnie
|
||||
|
||||
Przeznaczenie:
|
||||
|
||||
- `prometheus` zbiera metryki z `k3s` i z aplikacji
|
||||
- `grafana` daje dashboardy
|
||||
- `loki/promtail` sa opcjonalne do logow
|
||||
|
||||
### Namespace `infra`
|
||||
|
||||
- `Deployment` `argocd-server` albo kontrolery `flux`
|
||||
- `Deployment` `argocd-repo-server` jesli wybierzemy `Argo CD`
|
||||
- `Deployment` `sealed-secrets-controller` albo integracja `sops`
|
||||
- `Secret` / `ExternalSecret` dla tokenow i kluczy
|
||||
|
||||
Przeznaczenie:
|
||||
|
||||
- GitOps sync z Gitea
|
||||
- zarzadzanie sekretami
|
||||
- bootstrap aplikacji i manifestow
|
||||
|
||||
## Service exposure rules
|
||||
|
||||
- tylko `frontend` i `api` wychodza przez `Ingress`
|
||||
- `postgres`, `redis`, `clickhouse`, `strategy-engine`, `tx-router` zostaja wewnetrzne jako `ClusterIP`
|
||||
- bez `LoadBalancer`
|
||||
- bez publicznego wystawiania komponentow tradingowych
|
||||
- `yellowstone-consumer` nie potrzebuje publicznego `Service`
|
||||
|
||||
## Storage rules
|
||||
|
||||
- `postgres` na trwałym wolumenie
|
||||
- `clickhouse` tylko na szybkim lokalnym storage
|
||||
- `redis` bez PVC jesli ma byc tylko cache
|
||||
- aplikacje tradingowe jako stateless `Deployment`, jesli stan trzymamy w `postgres`
|
||||
|
||||
## Config and secrets
|
||||
|
||||
- `ConfigMap` dla endpointow, feature flags i runtime config
|
||||
- `Secret` dla:
|
||||
- tokenu Yellowstone
|
||||
- kluczy API
|
||||
- danych do `postgres`
|
||||
- danych do `Jito`
|
||||
- kluczy signing/delegate
|
||||
|
||||
## Kolejnosc wdrozenia w k3s
|
||||
|
||||
1. `infra`: GitOps i secrets
|
||||
2. `data`: `postgres`
|
||||
3. `web`: `frontend`, `api`, `Ingress`
|
||||
4. `trade`: `yellowstone-consumer`
|
||||
5. `trade`: `strategy-engine`, `risk-manager`, `order-manager`
|
||||
6. `trade`: `tx-router`
|
||||
7. `ops`: `prometheus`, `grafana`
|
||||
1082
doc/mevnode-bot-topology-interactive.html
Normal file
1082
doc/mevnode-bot-topology-interactive.html
Normal file
File diff suppressed because it is too large
Load Diff
424
doc/mevnode-bot-topology.html
Normal file
424
doc/mevnode-bot-topology.html
Normal file
@@ -0,0 +1,424 @@
|
||||
<!doctype html>
|
||||
<html lang="pl">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>mevnode topology</title>
|
||||
<style>
|
||||
:root {
|
||||
--bg: #f4efe7;
|
||||
--panel: #fffaf2;
|
||||
--ink: #1f1c17;
|
||||
--muted: #6b6358;
|
||||
--line: #d9ccb7;
|
||||
--accent: #b6412f;
|
||||
--accent-2: #0e6f74;
|
||||
--accent-3: #7c5e10;
|
||||
--shadow: 0 18px 40px rgba(31, 28, 23, 0.08);
|
||||
--radius: 18px;
|
||||
}
|
||||
|
||||
* { box-sizing: border-box; }
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
font-family: "IBM Plex Sans", "Segoe UI", sans-serif;
|
||||
background:
|
||||
radial-gradient(circle at top left, rgba(182, 65, 47, 0.12), transparent 28%),
|
||||
radial-gradient(circle at top right, rgba(14, 111, 116, 0.12), transparent 24%),
|
||||
linear-gradient(180deg, #fbf7f0 0%, var(--bg) 100%);
|
||||
color: var(--ink);
|
||||
}
|
||||
|
||||
.page {
|
||||
max-width: 1480px;
|
||||
margin: 0 auto;
|
||||
padding: 32px 20px 48px;
|
||||
}
|
||||
|
||||
.hero {
|
||||
display: grid;
|
||||
grid-template-columns: 1.2fr 0.8fr;
|
||||
gap: 24px;
|
||||
margin-bottom: 24px;
|
||||
}
|
||||
|
||||
.hero-card,
|
||||
.legend,
|
||||
.node,
|
||||
.strip,
|
||||
.note {
|
||||
background: rgba(255, 250, 242, 0.88);
|
||||
border: 1px solid rgba(217, 204, 183, 0.9);
|
||||
border-radius: var(--radius);
|
||||
box-shadow: var(--shadow);
|
||||
backdrop-filter: blur(10px);
|
||||
}
|
||||
|
||||
.hero-card {
|
||||
padding: 28px;
|
||||
}
|
||||
|
||||
.eyebrow {
|
||||
display: inline-block;
|
||||
padding: 6px 10px;
|
||||
border-radius: 999px;
|
||||
border: 1px solid rgba(182, 65, 47, 0.22);
|
||||
color: var(--accent);
|
||||
font-size: 12px;
|
||||
font-weight: 700;
|
||||
letter-spacing: 0.08em;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
h1 {
|
||||
margin: 16px 0 10px;
|
||||
font-family: "IBM Plex Serif", Georgia, serif;
|
||||
font-size: clamp(2rem, 4vw, 3.8rem);
|
||||
line-height: 0.98;
|
||||
}
|
||||
|
||||
.hero-card p,
|
||||
.legend p,
|
||||
.note p,
|
||||
.box p,
|
||||
.strip p {
|
||||
margin: 0;
|
||||
color: var(--muted);
|
||||
line-height: 1.55;
|
||||
}
|
||||
|
||||
.legend {
|
||||
padding: 24px;
|
||||
display: grid;
|
||||
gap: 14px;
|
||||
align-content: start;
|
||||
}
|
||||
|
||||
.legend-item {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 12px;
|
||||
color: var(--ink);
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.swatch {
|
||||
width: 14px;
|
||||
height: 14px;
|
||||
border-radius: 999px;
|
||||
flex: 0 0 14px;
|
||||
}
|
||||
|
||||
.swatch.read { background: var(--accent-2); }
|
||||
.swatch.write { background: var(--accent); }
|
||||
.swatch.ops { background: var(--accent-3); }
|
||||
.swatch.store { background: #4a5565; }
|
||||
|
||||
.diagram {
|
||||
display: grid;
|
||||
grid-template-columns: minmax(280px, 0.9fr) 120px minmax(320px, 1.25fr);
|
||||
gap: 18px;
|
||||
align-items: stretch;
|
||||
}
|
||||
|
||||
.node {
|
||||
padding: 20px;
|
||||
}
|
||||
|
||||
.node h2 {
|
||||
margin: 0 0 12px;
|
||||
font-size: 1.35rem;
|
||||
font-family: "IBM Plex Serif", Georgia, serif;
|
||||
}
|
||||
|
||||
.node-head {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: baseline;
|
||||
gap: 12px;
|
||||
margin-bottom: 14px;
|
||||
}
|
||||
|
||||
.node-head span {
|
||||
color: var(--muted);
|
||||
font-size: 13px;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.stack {
|
||||
display: grid;
|
||||
gap: 10px;
|
||||
}
|
||||
|
||||
.box {
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 14px;
|
||||
padding: 14px;
|
||||
background: #fffdf8;
|
||||
}
|
||||
|
||||
.box h3 {
|
||||
margin: 0 0 6px;
|
||||
font-size: 1rem;
|
||||
}
|
||||
|
||||
.box ul {
|
||||
margin: 10px 0 0;
|
||||
padding-left: 18px;
|
||||
color: var(--ink);
|
||||
}
|
||||
|
||||
.box li {
|
||||
margin: 6px 0;
|
||||
line-height: 1.45;
|
||||
}
|
||||
|
||||
.box.read { border-left: 6px solid var(--accent-2); }
|
||||
.box.write { border-left: 6px solid var(--accent); }
|
||||
.box.ops { border-left: 6px solid var(--accent-3); }
|
||||
.box.store { border-left: 6px solid #4a5565; }
|
||||
|
||||
.bridge {
|
||||
display: grid;
|
||||
grid-template-rows: 1fr auto 1fr auto 1fr;
|
||||
align-items: center;
|
||||
justify-items: center;
|
||||
color: var(--muted);
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.bridge-line {
|
||||
width: 2px;
|
||||
height: 100%;
|
||||
background:
|
||||
linear-gradient(180deg,
|
||||
rgba(14, 111, 116, 0.95) 0%,
|
||||
rgba(14, 111, 116, 0.95) 38%,
|
||||
rgba(182, 65, 47, 0.95) 38%,
|
||||
rgba(182, 65, 47, 0.95) 72%,
|
||||
rgba(124, 94, 16, 0.95) 72%,
|
||||
rgba(124, 94, 16, 0.95) 100%);
|
||||
border-radius: 999px;
|
||||
min-height: 88px;
|
||||
}
|
||||
|
||||
.bridge-tag {
|
||||
writing-mode: vertical-rl;
|
||||
transform: rotate(180deg);
|
||||
padding: 10px 0;
|
||||
font-size: 12px;
|
||||
letter-spacing: 0.08em;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
.strips {
|
||||
margin-top: 24px;
|
||||
display: grid;
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
gap: 18px;
|
||||
}
|
||||
|
||||
.strip {
|
||||
padding: 18px;
|
||||
}
|
||||
|
||||
.strip h3 {
|
||||
margin: 0 0 10px;
|
||||
font-size: 1rem;
|
||||
}
|
||||
|
||||
.strip code,
|
||||
.note code {
|
||||
font-family: "IBM Plex Mono", "Fira Code", monospace;
|
||||
font-size: 0.95em;
|
||||
background: rgba(31, 28, 23, 0.06);
|
||||
padding: 2px 6px;
|
||||
border-radius: 6px;
|
||||
}
|
||||
|
||||
.note {
|
||||
margin-top: 24px;
|
||||
padding: 18px 20px;
|
||||
}
|
||||
|
||||
@media (max-width: 1120px) {
|
||||
.hero,
|
||||
.diagram,
|
||||
.strips {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
|
||||
.bridge {
|
||||
grid-template-columns: 1fr auto 1fr auto 1fr;
|
||||
grid-template-rows: unset;
|
||||
}
|
||||
|
||||
.bridge-line {
|
||||
width: 100%;
|
||||
height: 2px;
|
||||
min-height: 2px;
|
||||
}
|
||||
|
||||
.bridge-tag {
|
||||
writing-mode: horizontal-tb;
|
||||
transform: none;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="page">
|
||||
<section class="hero">
|
||||
<div class="hero-card">
|
||||
<div class="eyebrow">Topology / mev stack</div>
|
||||
<h1>mevnode_sol daje chain access. mevnode_bot robi produkt, ingest i execution.</h1>
|
||||
<p>
|
||||
Ten układ rozdziela warstwę validatora od warstwy aplikacyjnej. Na <strong>sol</strong>
|
||||
trzymasz tylko Agave, Yellowstone i lokalne RPC. Na <strong>bot</strong> działa
|
||||
<strong>single-node k3s</strong> z frontendem, API, DLOB, strategiami i bazami danych.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<aside class="legend">
|
||||
<div class="legend-item"><span class="swatch read"></span> Read path: Yellowstone / live stream</div>
|
||||
<div class="legend-item"><span class="swatch write"></span> Write path: RPC / TPU / Jito</div>
|
||||
<div class="legend-item"><span class="swatch ops"></span> Ops path: monitoring, metryki, GitOps</div>
|
||||
<div class="legend-item"><span class="swatch store"></span> Data path: Postgres, Redis, analityka</div>
|
||||
<p>
|
||||
Zasada jest prosta: <strong>na bot nie trafia nigdy Agave ani ledger</strong>.
|
||||
`mevnode_bot` ma tylko klienty, logikę tradingową i interfejs użytkownika.
|
||||
</p>
|
||||
</aside>
|
||||
</section>
|
||||
|
||||
<section class="diagram">
|
||||
<article class="node">
|
||||
<div class="node-head">
|
||||
<h2>mevnode_sol</h2>
|
||||
<span>bare metal / validator host</span>
|
||||
</div>
|
||||
<div class="stack">
|
||||
<div class="box read">
|
||||
<h3>Agave validator</h3>
|
||||
<p>Źródło stanu chaina, snapshotów i lokalnego read/write RPC.</p>
|
||||
<ul>
|
||||
<li><code>127.0.0.1:8899</code> RPC</li>
|
||||
<li><code>10.91.0.1:10000</code> Yellowstone gRPC</li>
|
||||
<li><code>10.91.0.1:8999</code> Prometheus plugin metrics</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box write">
|
||||
<h3>Write capability</h3>
|
||||
<p>Bot może później używać lokalnego RPC przez proxy lub iść bezpośrednio przez TPU/Jito.</p>
|
||||
</div>
|
||||
|
||||
<div class="box ops">
|
||||
<h3>Node-only responsibilities</h3>
|
||||
<ul>
|
||||
<li>snapshot recovery</li>
|
||||
<li>accounts index</li>
|
||||
<li>geyser / yellowstone plugin</li>
|
||||
<li>node metrics</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<div class="bridge" aria-hidden="true">
|
||||
<div class="bridge-line"></div>
|
||||
<div class="bridge-tag">wg0 / yellowstone / rpc / metrics</div>
|
||||
<div class="bridge-line"></div>
|
||||
<div class="bridge-tag">low latency read + controlled write</div>
|
||||
<div class="bridge-line"></div>
|
||||
</div>
|
||||
|
||||
<article class="node">
|
||||
<div class="node-head">
|
||||
<h2>mevnode_bot</h2>
|
||||
<span>single-node k3s / app + execution host</span>
|
||||
</div>
|
||||
<div class="stack">
|
||||
<div class="box read">
|
||||
<h3>Read plane</h3>
|
||||
<ul>
|
||||
<li><strong>yellowstone-consumer</strong>: bierze live stream z <code>10.91.0.1:10000</code></li>
|
||||
<li><strong>trade-ingestor</strong>: transformuje i dystrybuuje dane aplikacyjne</li>
|
||||
<li><strong>dlob-publisher</strong>: dociąga stan kont przez RPC i buduje DLOB</li>
|
||||
<li><strong>dlob-server</strong>: wystawia gotowy widok dla API i UI</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box write">
|
||||
<h3>Execution plane</h3>
|
||||
<ul>
|
||||
<li><strong>strategy-engine</strong>: decyzje tradingowe</li>
|
||||
<li><strong>risk-manager</strong>: limity i walidacja</li>
|
||||
<li><strong>order-manager</strong>: lifecycle zleceń</li>
|
||||
<li><strong>tx-router</strong>: wybiera <code>RPC</code>, <code>TPU</code> albo <code>Jito</code></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box store">
|
||||
<h3>Data plane</h3>
|
||||
<ul>
|
||||
<li><strong>Postgres</strong>: trwały storage, pozycje, historia, config</li>
|
||||
<li><strong>Hasura</strong>: warstwa GraphQL nad Postgres</li>
|
||||
<li><strong>Redis</strong>: cache, pub/sub, szybki stan DLOB</li>
|
||||
<li><strong>ClickHouse</strong>: opcjonalnie później pod cięższą analitykę</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box ops">
|
||||
<h3>Product and ops</h3>
|
||||
<ul>
|
||||
<li><strong>frontend</strong> + <strong>api</strong> + <strong>ingress</strong></li>
|
||||
<li><strong>Prometheus</strong> + <strong>Grafana</strong></li>
|
||||
<li><strong>Portainer agent</strong> dla widoczności klastra w Portainerze</li>
|
||||
<li><strong>GitOps</strong>: Argo lub Flux z Gitea</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
</section>
|
||||
|
||||
<section class="strips">
|
||||
<div class="strip">
|
||||
<h3>Read path</h3>
|
||||
<p>
|
||||
<code>Yellowstone gRPC</code> daje live account updates, sloty i transakcje.
|
||||
<code>Agave RPC</code> zostaje do odczytów punktowych typu
|
||||
<code>getAccountInfo</code>, <code>getMultipleAccounts</code>,
|
||||
<code>getHealth</code> i <code>getLatestBlockhash</code>.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="strip">
|
||||
<h3>Write path</h3>
|
||||
<p>
|
||||
Wysyłka transakcji nie idzie przez Yellowstone. To robi
|
||||
<code>RPC</code>, <code>TPU</code> albo <code>Jito</code>.
|
||||
Dzięki temu read plane i write plane są od siebie operacyjnie odseparowane.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="strip">
|
||||
<h3>Deployment rule</h3>
|
||||
<p>
|
||||
Wszystko aplikacyjne i webowe ląduje na <code>mevnode_bot</code>.
|
||||
Wszystko validatorowe zostaje na <code>mevnode_sol</code>.
|
||||
To upraszcza debug, upgrade i kontrolę ryzyka.
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="note">
|
||||
<p>
|
||||
Docelowy przepływ: <code>mevnode_sol -> wg0 -> yellowstone-consumer / dlob-publisher -> redis / postgres -> api -> frontend</code>.
|
||||
Osobno działa execution path: <code>strategy-engine -> tx-router -> RPC / TPU / Jito</code>.
|
||||
</p>
|
||||
</section>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
692
doc/trade-system-flow.html
Normal file
692
doc/trade-system-flow.html
Normal file
@@ -0,0 +1,692 @@
|
||||
<!doctype html>
|
||||
<html lang="pl">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Trade system flow</title>
|
||||
<style>
|
||||
:root {
|
||||
--bg: #efe7db;
|
||||
--paper: rgba(255, 251, 245, 0.94);
|
||||
--panel: #fffdf9;
|
||||
--ink: #1c1814;
|
||||
--muted: #655d53;
|
||||
--line: #d9ccb9;
|
||||
--web: #2a6b8f;
|
||||
--api: #0f6c72;
|
||||
--data: #4e5968;
|
||||
--chain: #b24a32;
|
||||
--exec: #7b6110;
|
||||
--ok: #1d6b43;
|
||||
--warn: #914017;
|
||||
--shadow: 0 18px 44px rgba(28, 24, 20, 0.10);
|
||||
--radius: 18px;
|
||||
}
|
||||
|
||||
* { box-sizing: border-box; }
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
color: var(--ink);
|
||||
font-family: "IBM Plex Sans", "Segoe UI", sans-serif;
|
||||
background:
|
||||
radial-gradient(circle at top left, rgba(42, 107, 143, 0.12), transparent 28%),
|
||||
radial-gradient(circle at top right, rgba(178, 74, 50, 0.12), transparent 24%),
|
||||
linear-gradient(180deg, #f8f3eb 0%, var(--bg) 100%);
|
||||
}
|
||||
|
||||
.page {
|
||||
max-width: 1540px;
|
||||
margin: 0 auto;
|
||||
padding: 28px 18px 42px;
|
||||
}
|
||||
|
||||
.hero,
|
||||
.card,
|
||||
.table-card,
|
||||
.lane,
|
||||
.note,
|
||||
.tabs {
|
||||
background: var(--paper);
|
||||
border: 1px solid rgba(217, 204, 185, 0.9);
|
||||
border-radius: var(--radius);
|
||||
box-shadow: var(--shadow);
|
||||
backdrop-filter: blur(10px);
|
||||
}
|
||||
|
||||
.hero {
|
||||
padding: 26px;
|
||||
margin-bottom: 18px;
|
||||
}
|
||||
|
||||
.eyebrow {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
gap: 8px;
|
||||
padding: 6px 10px;
|
||||
border-radius: 999px;
|
||||
border: 1px solid rgba(28, 24, 20, 0.10);
|
||||
color: var(--muted);
|
||||
font-size: 12px;
|
||||
font-weight: 800;
|
||||
letter-spacing: 0.08em;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
h1 {
|
||||
margin: 14px 0 10px;
|
||||
font-size: clamp(2rem, 4vw, 3.9rem);
|
||||
line-height: 0.96;
|
||||
font-family: "IBM Plex Serif", Georgia, serif;
|
||||
}
|
||||
|
||||
p {
|
||||
margin: 0;
|
||||
color: var(--muted);
|
||||
line-height: 1.58;
|
||||
}
|
||||
|
||||
.tabs {
|
||||
display: flex;
|
||||
gap: 10px;
|
||||
flex-wrap: wrap;
|
||||
padding: 12px;
|
||||
margin-bottom: 18px;
|
||||
}
|
||||
|
||||
.tab {
|
||||
border: 1px solid var(--line);
|
||||
background: #fffaf2;
|
||||
border-radius: 999px;
|
||||
padding: 10px 14px;
|
||||
font: inherit;
|
||||
font-weight: 800;
|
||||
cursor: pointer;
|
||||
transition: 150ms ease;
|
||||
}
|
||||
|
||||
.tab.active,
|
||||
.tab:hover {
|
||||
transform: translateY(-1px);
|
||||
box-shadow: 0 10px 22px rgba(28, 24, 20, 0.08);
|
||||
}
|
||||
|
||||
.tab[data-target="overview"].active { color: var(--web); }
|
||||
.tab[data-target="routes"].active { color: var(--api); }
|
||||
.tab[data-target="payloads"].active { color: var(--chain); }
|
||||
|
||||
.view { display: none; }
|
||||
.view.active { display: block; }
|
||||
|
||||
.lanes {
|
||||
display: grid;
|
||||
grid-template-columns: 1.05fr 0.9fr 0.95fr;
|
||||
gap: 16px;
|
||||
margin-bottom: 18px;
|
||||
}
|
||||
|
||||
.lane {
|
||||
padding: 16px;
|
||||
}
|
||||
|
||||
.lane h2 {
|
||||
margin: 0 0 6px;
|
||||
font-size: 1.2rem;
|
||||
font-family: "IBM Plex Serif", Georgia, serif;
|
||||
}
|
||||
|
||||
.lane small {
|
||||
display: block;
|
||||
color: var(--muted);
|
||||
margin-bottom: 14px;
|
||||
line-height: 1.45;
|
||||
}
|
||||
|
||||
.stack {
|
||||
display: grid;
|
||||
gap: 12px;
|
||||
}
|
||||
|
||||
.card {
|
||||
padding: 14px;
|
||||
background: var(--panel);
|
||||
border-left: 6px solid var(--line);
|
||||
}
|
||||
|
||||
.card h3 {
|
||||
margin: 0 0 6px;
|
||||
font-size: 1rem;
|
||||
}
|
||||
|
||||
.meta {
|
||||
font-size: 11px;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.08em;
|
||||
color: var(--muted);
|
||||
font-weight: 800;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
|
||||
.card.web { border-left-color: var(--web); }
|
||||
.card.api { border-left-color: var(--api); }
|
||||
.card.data { border-left-color: var(--data); }
|
||||
.card.chain { border-left-color: var(--chain); }
|
||||
.card.exec { border-left-color: var(--exec); }
|
||||
|
||||
.chips {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 8px;
|
||||
margin-top: 10px;
|
||||
}
|
||||
|
||||
.chip {
|
||||
display: inline-block;
|
||||
padding: 4px 8px;
|
||||
border-radius: 999px;
|
||||
font-size: 12px;
|
||||
font-weight: 700;
|
||||
background: rgba(28, 24, 20, 0.06);
|
||||
}
|
||||
|
||||
.flow {
|
||||
display: grid;
|
||||
gap: 14px;
|
||||
margin-top: 12px;
|
||||
}
|
||||
|
||||
.flow-row {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(5, minmax(0, 1fr));
|
||||
gap: 12px;
|
||||
align-items: stretch;
|
||||
}
|
||||
|
||||
.flow-node {
|
||||
padding: 14px;
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 14px;
|
||||
background: #fffdf9;
|
||||
min-height: 118px;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.flow-node strong {
|
||||
display: block;
|
||||
margin-bottom: 8px;
|
||||
font-size: 0.98rem;
|
||||
}
|
||||
|
||||
.arrow {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
font-size: 24px;
|
||||
color: var(--muted);
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.table-card {
|
||||
padding: 14px;
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
table {
|
||||
width: 100%;
|
||||
border-collapse: collapse;
|
||||
min-width: 980px;
|
||||
}
|
||||
|
||||
th,
|
||||
td {
|
||||
padding: 12px 10px;
|
||||
border-bottom: 1px solid var(--line);
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
line-height: 1.45;
|
||||
}
|
||||
|
||||
th {
|
||||
font-size: 12px;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.08em;
|
||||
color: var(--muted);
|
||||
}
|
||||
|
||||
code,
|
||||
pre {
|
||||
font-family: "IBM Plex Mono", monospace;
|
||||
}
|
||||
|
||||
pre {
|
||||
margin: 0;
|
||||
white-space: pre-wrap;
|
||||
word-break: break-word;
|
||||
background: rgba(28, 24, 20, 0.04);
|
||||
border-radius: 12px;
|
||||
padding: 14px;
|
||||
line-height: 1.45;
|
||||
}
|
||||
|
||||
.payload-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2, 1fr);
|
||||
gap: 16px;
|
||||
}
|
||||
|
||||
.note {
|
||||
padding: 16px 18px;
|
||||
margin-top: 18px;
|
||||
}
|
||||
|
||||
.status {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
gap: 6px;
|
||||
font-size: 12px;
|
||||
font-weight: 800;
|
||||
padding: 4px 8px;
|
||||
border-radius: 999px;
|
||||
background: rgba(28, 24, 20, 0.06);
|
||||
}
|
||||
|
||||
.ok { color: var(--ok); background: rgba(29, 107, 67, 0.10); }
|
||||
.warn { color: var(--warn); background: rgba(178, 74, 50, 0.10); }
|
||||
|
||||
@media (max-width: 1220px) {
|
||||
.lanes,
|
||||
.payload-grid,
|
||||
.flow-row {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
|
||||
.arrow {
|
||||
transform: rotate(90deg);
|
||||
min-height: 32px;
|
||||
}
|
||||
|
||||
table { min-width: 720px; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="page">
|
||||
<section class="hero">
|
||||
<div class="eyebrow">Trade architecture / runtime map</div>
|
||||
<h1>Skąd dane trafiają, w jakiej postaci i które endpointy naprawdę wystawiamy</h1>
|
||||
<p>
|
||||
Ta strona opisuje faktyczny przepływ runtime dla waszej appki: <strong>browser -> frontend -> API/Hasura -> Postgres/Redis</strong>
|
||||
oraz zależności od <strong>Agave RPC</strong> i <strong>Yellowstone gRPC</strong>. To nie jest ogólny diagram architektury,
|
||||
tylko mapa wejść, wyjść, formatów danych i tras HTTP/WS używanych przez produkt.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section class="tabs">
|
||||
<button class="tab active" data-target="overview">Overview</button>
|
||||
<button class="tab" data-target="routes">Routes / APIs</button>
|
||||
<button class="tab" data-target="payloads">Payloads / shapes</button>
|
||||
</section>
|
||||
|
||||
<section class="view active" id="overview">
|
||||
<div class="lanes">
|
||||
<article class="lane">
|
||||
<h2>Public web surface</h2>
|
||||
<small>To widzi użytkownik i to jest jedyny realny entrypoint produktu na zewnątrz.</small>
|
||||
<div class="stack">
|
||||
<div class="card web">
|
||||
<div class="meta">NodePort / browser entry</div>
|
||||
<h3>trade-frontend</h3>
|
||||
<p>Serwuje SPA, obsługuje logowanie, robi proxy do API i Hasury.</p>
|
||||
<div class="chips">
|
||||
<span class="chip">NodePort 30081</span>
|
||||
<span class="chip">service 8081</span>
|
||||
<span class="chip">/api/*</span>
|
||||
<span class="chip">/graphql</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="card web">
|
||||
<div class="meta">Browser calls</div>
|
||||
<h3>Frontend SPA</h3>
|
||||
<p>Wykres bierze REST JSON. DLOB live bierze GraphQL WebSocket. Auth idzie przez sesję cookie.</p>
|
||||
<div class="chips">
|
||||
<span class="chip">GET /whoami</span>
|
||||
<span class="chip">POST /auth/login</span>
|
||||
<span class="chip">GET /api/v1/chart</span>
|
||||
<span class="chip">WS /graphql</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<article class="lane">
|
||||
<h2>App services in k3s</h2>
|
||||
<small>Wewnętrzne usługi aplikacyjne. Tylko frontend jest dziś wystawiony na zewnątrz jako NodePort.</small>
|
||||
<div class="stack">
|
||||
<div class="card api">
|
||||
<div class="meta">ClusterIP / app logic</div>
|
||||
<h3>trade-api</h3>
|
||||
<p>REST backend. Zwraca candles, przyjmuje tick ingest, zarządza tokenami.</p>
|
||||
<div class="chips">
|
||||
<span class="chip">ClusterIP 8787</span>
|
||||
<span class="chip">/v1/chart</span>
|
||||
<span class="chip">/v1/ticks</span>
|
||||
<span class="chip">/v1/ingest/tick</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="card data">
|
||||
<div class="meta">ClusterIP / query plane</div>
|
||||
<h3>Hasura + Postgres</h3>
|
||||
<p>Frontend subskrybuje Hasurę po GraphQL WS. API czyta i zapisuje przez GraphQL do Hasury.</p>
|
||||
<div class="chips">
|
||||
<span class="chip">Hasura 8080</span>
|
||||
<span class="chip">Postgres 5432</span>
|
||||
<span class="chip">GraphQL</span>
|
||||
<span class="chip">subscriptions</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="card data">
|
||||
<div class="meta">Redis-backed read side</div>
|
||||
<h3>DLOB stack</h3>
|
||||
<p><span class="status warn">publisher 0/1</span> <span class="status warn">server 0/1</span> bo bootstrapping zależy od zdrowego Agave RPC.</p>
|
||||
<div class="chips">
|
||||
<span class="chip">Redis 6379</span>
|
||||
<span class="chip">dlob-server 6969</span>
|
||||
<span class="chip">workers</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<article class="lane">
|
||||
<h2>Chain and execution plane</h2>
|
||||
<small>To nie jest wystawiane użytkownikowi końcowemu. To feed i write side dla botów.</small>
|
||||
<div class="stack">
|
||||
<div class="card chain">
|
||||
<div class="meta">mevnode_sol / source of truth</div>
|
||||
<h3>Agave RPC</h3>
|
||||
<p>Punktowe odczyty: <code>getAccountInfo</code>, <code>getMultipleAccounts</code>, <code>getSlot</code>, <code>getHealth</code>.</p>
|
||||
<div class="chips">
|
||||
<span class="chip">127.0.0.1:8899</span>
|
||||
<span class="chip">RPC only</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="card chain">
|
||||
<div class="meta">mevnode_sol / live feed</div>
|
||||
<h3>Yellowstone gRPC</h3>
|
||||
<p>Pushowy stream kont, slotów i transakcji po <code>wg0</code>.</p>
|
||||
<div class="chips">
|
||||
<span class="chip">10.91.0.1:10000</span>
|
||||
<span class="chip">token auth</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="card exec">
|
||||
<div class="meta">future execution split</div>
|
||||
<h3>tx-router / TPU / Jito</h3>
|
||||
<p>To jest write path. Nie mylić z Yellowstone, który jest tylko read streamem.</p>
|
||||
</div>
|
||||
</div>
|
||||
</article>
|
||||
</div>
|
||||
|
||||
<div class="table-card">
|
||||
<div class="meta">End-to-end runtime flow</div>
|
||||
<div class="flow">
|
||||
<div class="flow-row">
|
||||
<div class="flow-node"><strong>1. Browser</strong>Użytkownik otwiera SPA i trzyma sesję cookie.</div>
|
||||
<div class="arrow">→</div>
|
||||
<div class="flow-node"><strong>2. trade-frontend</strong>Serwuje UI i robi reverse proxy do <code>/api</code> i <code>/graphql</code>.</div>
|
||||
<div class="arrow">→</div>
|
||||
<div class="flow-node"><strong>3. trade-api / Hasura</strong>REST dla chartów, GraphQL WS dla live DLOB.</div>
|
||||
</div>
|
||||
<div class="flow-row">
|
||||
<div class="flow-node"><strong>4. Postgres / Redis</strong>Trwały stan i szybki stan pośredni.</div>
|
||||
<div class="arrow">←</div>
|
||||
<div class="flow-node"><strong>5. DLOB workers</strong>Przeliczają depth, slippage, orderbook views.</div>
|
||||
<div class="arrow">←</div>
|
||||
<div class="flow-node"><strong>6. Agave / Yellowstone</strong>RPC do odczytów punktowych, gRPC do streamu live.</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="note">
|
||||
<p>
|
||||
Najważniejszy podział: <strong>chart path = REST JSON przez trade-api</strong>, a <strong>DLOB live = GraphQL WS przez Hasurę</strong>.
|
||||
To oznacza, że nie cały frontend jedzie jednym typem transportu. Produkt ma dwa równoległe read pathy.
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="view" id="routes">
|
||||
<div class="table-card">
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Surface</th>
|
||||
<th>Endpoint</th>
|
||||
<th>Transport</th>
|
||||
<th>Input</th>
|
||||
<th>Output</th>
|
||||
<th>Where it goes</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Frontend</td>
|
||||
<td><code>GET /whoami</code></td>
|
||||
<td>HTTP JSON</td>
|
||||
<td>cookie session</td>
|
||||
<td><code>{ ok, user, mode }</code></td>
|
||||
<td>handled directly by <code>trade-frontend</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Frontend</td>
|
||||
<td><code>POST /auth/login</code></td>
|
||||
<td>HTTP JSON/form</td>
|
||||
<td><code>username</code>, <code>password</code></td>
|
||||
<td><code>{ ok, user }</code> + session cookie</td>
|
||||
<td>handled directly by <code>trade-frontend</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Frontend</td>
|
||||
<td><code>POST /auth/logout</code></td>
|
||||
<td>HTTP JSON</td>
|
||||
<td>session cookie</td>
|
||||
<td><code>{ ok: true }</code></td>
|
||||
<td>handled directly by <code>trade-frontend</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Frontend proxy</td>
|
||||
<td><code>/api/*</code></td>
|
||||
<td>HTTP</td>
|
||||
<td>browser request, frontend injects read token</td>
|
||||
<td>proxied API response</td>
|
||||
<td><code>trade-api:8787</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Frontend proxy</td>
|
||||
<td><code>/graphql</code></td>
|
||||
<td>HTTP GraphQL</td>
|
||||
<td>GraphQL query/mutation</td>
|
||||
<td>GraphQL response</td>
|
||||
<td><code>hasura:8080/v1/graphql</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Frontend proxy</td>
|
||||
<td><code>WS /graphql</code></td>
|
||||
<td>GraphQL WebSocket</td>
|
||||
<td>subscription payload</td>
|
||||
<td>live subscription frames</td>
|
||||
<td><code>hasura:8080/v1/graphql</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>API</td>
|
||||
<td><code>GET /v1/chart</code></td>
|
||||
<td>HTTP JSON</td>
|
||||
<td><code>symbol</code>, <code>tf</code>, <code>limit</code>, optional <code>source</code></td>
|
||||
<td>candles + indicators + flow rows</td>
|
||||
<td>Hasura function <code>get_drift_candles</code> + table <code>drift_ticks</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>API</td>
|
||||
<td><code>POST /v1/ingest/tick</code></td>
|
||||
<td>HTTP JSON</td>
|
||||
<td>tick payload</td>
|
||||
<td><code>{ ok, id }</code></td>
|
||||
<td>writes tick through Hasura into DB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>API</td>
|
||||
<td><code>GET /v1/ticks</code></td>
|
||||
<td>HTTP JSON</td>
|
||||
<td><code>symbol</code>, optional <code>source</code>, <code>limit</code>, <code>from</code>, <code>to</code></td>
|
||||
<td>tick list</td>
|
||||
<td>reads <code>drift_ticks</code> through Hasura</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>API admin</td>
|
||||
<td><code>POST /v1/admin/tokens</code></td>
|
||||
<td>HTTP JSON</td>
|
||||
<td>name, scopes</td>
|
||||
<td>new API token</td>
|
||||
<td>stored in DB via Hasura</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>API admin</td>
|
||||
<td><code>POST /v1/admin/tokens/revoke</code></td>
|
||||
<td>HTTP JSON</td>
|
||||
<td>token id</td>
|
||||
<td>revocation status</td>
|
||||
<td>updates token row in DB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Chain read</td>
|
||||
<td><code>Agave RPC</code></td>
|
||||
<td>JSON-RPC</td>
|
||||
<td>account/state requests</td>
|
||||
<td>point reads</td>
|
||||
<td><code>mevnode_sol</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Chain live</td>
|
||||
<td><code>Yellowstone gRPC</code></td>
|
||||
<td>gRPC streaming</td>
|
||||
<td>subscription config + token</td>
|
||||
<td>account/slot/tx stream</td>
|
||||
<td><code>mevnode_sol</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section class="view" id="payloads">
|
||||
<div class="payload-grid">
|
||||
<div class="table-card">
|
||||
<div class="meta">Chart response</div>
|
||||
<pre>{
|
||||
"ok": true,
|
||||
"symbol": "SOL-PERP",
|
||||
"tf": "1m",
|
||||
"bucketSeconds": 60,
|
||||
"candles": [
|
||||
{
|
||||
"time": 1710000000,
|
||||
"open": 132.1,
|
||||
"high": 133.2,
|
||||
"low": 131.8,
|
||||
"close": 132.9,
|
||||
"volume": 412,
|
||||
"oracle": 132.7,
|
||||
"flow": { "up": 0.46, "down": 0.41, "flat": 0.13 },
|
||||
"flowRows": [1, 1, 0, -1],
|
||||
"flowMoves": [0.2, 0.1, 0, 0.3]
|
||||
}
|
||||
],
|
||||
"indicators": {
|
||||
"sma20": [{ "time": 1710000000, "value": 131.4 }],
|
||||
"ema20": [{ "time": 1710000000, "value": 131.8 }],
|
||||
"bb20": { "upper": [], "lower": [], "mid": [] },
|
||||
"rsi14": [],
|
||||
"macd": { "macd": [], "signal": [] }
|
||||
}
|
||||
}</pre>
|
||||
</div>
|
||||
|
||||
<div class="table-card">
|
||||
<div class="meta">Tick ingest body</div>
|
||||
<pre>{
|
||||
"ts": "2026-03-13T11:20:00.000Z",
|
||||
"market_index": 0,
|
||||
"symbol": "SOL-PERP",
|
||||
"oracle_price": "132.70",
|
||||
"mark_price": "132.91",
|
||||
"oracle_slot": 406125100,
|
||||
"source": "drift",
|
||||
"raw": {
|
||||
"provider": "internal"
|
||||
}
|
||||
}</pre>
|
||||
</div>
|
||||
|
||||
<div class="table-card">
|
||||
<div class="meta">GraphQL DLOB subscriptions</div>
|
||||
<pre>subscription DlobStats($market: String!) {
|
||||
dlob_stats_latest(where: {market_name: {_eq: $market}}, limit: 1) {
|
||||
market_name
|
||||
mark_price
|
||||
oracle_price
|
||||
best_bid_price
|
||||
best_ask_price
|
||||
mid_price
|
||||
spread_abs
|
||||
spread_bps
|
||||
depth_bid_usd
|
||||
depth_ask_usd
|
||||
imbalance
|
||||
updated_at
|
||||
}
|
||||
}</pre>
|
||||
</div>
|
||||
|
||||
<div class="table-card">
|
||||
<div class="meta">L2 payload shape</div>
|
||||
<pre>{
|
||||
"market_name": "SOL-PERP",
|
||||
"bids": [
|
||||
{ "price": 132910000, "size": 2500000000 }
|
||||
],
|
||||
"asks": [
|
||||
{ "price": 132930000, "size": 1700000000 }
|
||||
],
|
||||
"updated_at": "2026-03-13T11:20:01.000Z"
|
||||
}
|
||||
|
||||
Frontend przelicza to przez:
|
||||
- pricePrecision = 1_000_000
|
||||
- basePrecision = 1_000_000_000</pre>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="note">
|
||||
<p>
|
||||
Krytyczne rozróżnienie: <strong>DLOB live nie idzie z REST API</strong>. DLOB do UI idzie przez <strong>Hasura GraphQL subscriptions</strong>,
|
||||
a chart przez <strong>REST JSON</strong> z <code>trade-api</code>. To są dwa osobne transporty, dwa osobne modele danych i dwa osobne źródła opóźnień.
|
||||
</p>
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
const tabs = [...document.querySelectorAll('.tab')];
|
||||
const views = [...document.querySelectorAll('.view')];
|
||||
|
||||
tabs.forEach((tab) => {
|
||||
tab.addEventListener('click', () => {
|
||||
const target = tab.dataset.target;
|
||||
tabs.forEach((x) => x.classList.toggle('active', x === tab));
|
||||
views.forEach((view) => view.classList.toggle('active', view.id === target));
|
||||
});
|
||||
});
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user