# 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`