Skálázási térkép

Tömeges — bírja-e 10 000 felhasználó?

Őszinte mérnöki térkép az EGÉSZ rendszerről (nem csak WIBO): komponensenként mi bírja most, mi törik el a növekedéssel, és pontosan mi kell a következő lépcsőhöz. Cél: a termék jó alapokon áll, a skálázás köréjük épül.

Amit eddig építettünk, az egy működő prototípus 1-2 felhasználóra — szándékosan. A 10 000-es skála egy külön, finanszírozott mérnöki fázis. A jó hír: a termék- és adat-alapok jók (több-bérlős, provider-független, cserélhető agy) → nem újraírás, hanem infrastruktúra a jó alapok köré. A kockázat nem az, hogy „nem megy 10k-ra", hanem hogy ha most nem tartjuk az elveket, később drága átállni.

A három lépcső

1-2 → 1 000 → 10 000

MOST · prototípus

1–2

Te + család. Egy VPS, egy IB-login, egy Claude-előfizetés. Minden „egy szálon". Cél: a TERMÉK bizonyítása — kész.

Korai éles

~1 000

Managed adatbázis-tuning + közös piaci-adat fanout + per-user bróker + BYO/kis inference. Néhány szolgáltatás duplázva, monitoring.

Tömeges

10 000

Vízszintesen skálázott réteg minden komponensre: WS-gateway cluster, inference-cluster, worker-queue-k, load-balancer, observability, SLA.

A térkép

Komponensenként: mi bírja, mi törik, mi kell

Ez a lényeg. Minden fő komponens jelenlegi állapota + a lépcsők.

Komponens	MOST (1-2)	~1 000 user	10 000 user
Élő-adat proxyIB Gateway + WhitePro + Binance	szűk keresztmetszet EGY VPS, EGY IB-login, EGY WhitePro-session. Ez a legérzékenyebb pont.	Szétválasztás: közös piaci adat (1 upstream → pub/sub broadcast) vs. per-user számla (mindenki a saját brókerét köti be).	Piaci-adat gateway cluster (Redis/NATS fanout), per-user bróker-kapcsolatok. 1 NVDA-feliratkozás → 10k-nak szórva.
WIBO (AI)a modell-hívás	nem skálázódik Egy előfizetés (tulaj), egy VPS, kérdésenként hidegindulás.	BYO-modell (user a sajátját) VAGY kis közös self-host inference + meleg-session (nincs hidegindulás).	Inference-cluster (GPU-k, load-balance) VAGY BYO-flotta. A cserélhető-agy már erre tervezve.
AdatbázisSupabase / Postgres	jó, de tuning kell Per-user RLS ✓. Egy instance, alap indexek.	Connection-pooling (Supavisor), indexek, olvasó-replika, cache. Háttér-munkák queue-ra.	Sharding/particionálás a nagy tábláknál (prices, events), dedikált replikák, cache-réteg (Redis).
Valós időWebSocket feed	egy szál A böngészők közvetlenül egy VPS-re. 10k egyidejű WS = nem.	WS-gateway réteg (2-3 node load-balancer mögött), a fanoutból táplálva.	Auto-skálázó WS-cluster (sticky/room-alapú), edge-közeli node-ok, backpressure.
Háttér-munkákalert-motor, snapshot, ingest	egy process Az alert-motor + NAV-snapshot + EOD-ingest egy szálon fut.	Queue + worker-ek (BullMQ/pg-boss), per-user sharding, retry/dead-letter.	Auto-skálázó worker-flotta, ütemező, idempotencia, megfigyelhetőség.
Frontendweb (Vercel) + mobil	skálázódik CDN + serverless — már most bírja.	Változatlan (CDN). Talán edge-cache a publikus adatokra.	Változatlan — ez a rész „ingyen" skálázódik.
Auth + izolációbejelentkezés, RLS	jó alap Supabase auth + per-user RLS + app-zár. Az elv kész.	Rate-limit, audit, szerep-modell (user/bróker-admin), több-bérlős tesztek.	SSO/bróker-szintű tenant-izoláció, biztonsági audit, megfelelőség (pénzügyi).

Hol állunk

Ami szilárd · ami a skála-fázis

✓ Szilárd alapok (nem újraírás)

Per-user adat-izoláció (RLS) — a többfelhasználós modell megvan.
Provider-független frontend (nem egy brókerhez kötött).
Cserélhető agy (WIBO: BYO vagy self-host, egy interfész).
Közös vs. személyes szétválasztás elve (piaci adat közös, számla személyes).
Frontend (web+mobil) — CDN-en skálázódik.

⚙ A skála-fázis munkája (infra)

Piaci-adat fanout (1 feed → sokan) + per-user bróker-bekötés.
WS-gateway cluster + load-balancer.
Inference-cluster vagy BYO-modell flotta a WIBO-hoz.
Queue + worker-ek a háttér-munkákhoz.
Megfigyelhetőség (metrikák, riasztás, SLA) + biztonsági/pénzügyi audit.

Amit MOST tartunk

3 elv, hogy a skálázás ne fájjon

Ezek most olcsók, később drágák — ezért építés közben végig tartjuk őket.

Szigorú per-user izoláció. Minden adat a felhasználó fiókjához kötve (RLS), semmi közös-írható állapot ami keveredhet.
Közös piaci adat ≠ per-user számla. Az árfolyam mindenkinek ugyanaz (egy forrásból szórva); a számla/kereskedés mindenkié a sajátja. Sose keverjük a kettőt egy csővezetékbe.
Állapotmentes szolgáltatások. Ahol lehet, a szerver ne tartson memóriában felhasználó-állapotot → vízszintesen duplázható lesz (több példány mögé load-balancer).

Az AI-réteg tömegben

WIBO 10 000 felhasználónál

WIBO minden usernél egy-egy példányként fut, folyamatosan kérdezik. A mostani prototípus (egy VPS, kérdésenként új CLI-folyamat, egy előfizetés) ezt NEM bírja — íme mi törik és mi kell.

⚠️ A mostani WIBO egy-felhasználós prototípus. 10k folyamatos kérdésnél összeomlik: egy 2-vCPU-s VPS kérdésenként új, nehéz claude-folyamatot indít (~10 mp boot, ~100 MB) → max 2-4 párhuzamosat bír, nem ezret; és egy előfizetést nem oszthat 10k user.

Réteg	Mi törik 10k-nál	Mi kell hozzá
Az agy (modell)	egy előfizetés Egy közös login → a keret azonnal elfogy.	Per-user agy: mindenki a SAJÁT modelljét (BYO), VAGY a bróker közös self-host inference-clustere (GPU-k, load-balance, auto-skálázás).
WIBO-gatewayrouter + tool + kontextus	egy VPS, CLI/kérdés Kérdésenként új folyamat → CPU/RAM azonnal elfogy.	Állapotmentes CLUSTER load-balancer mögött, sok példány, auto-skálázva. A logika könnyű (orkesztráció) → jól skálázódik. NINCS kérdésenkénti CLI-boot: valódi inference-végpont (self-host API / meleg pool).
Piaci-adat lekérés„mennyi a MOL?"	userenként külön fetch 10k user ugyanazt kérdezi → 10k felesleges lekérés.	⭐ Megosztott CACHE: „mennyi a MOL?" mindenkinek UGYANAZ → egy lekérés 1-5s cache-elve kiszolgál ezreket. Óriási hatékonyság.
Kapcsolat + adat	egy quick-tunnel Nem 10k egyidejű kapcsolatra való.	Stabil végpont (named tunnel / gateway), a proxy-fanout + DB-pooling (a fenti térkép szerint).
Gazdaságosság	API = per-token pénz 10k user × sok kérdés API-kulcson = drága.	Self-host modell → nincs per-user előfizetés/API-token-költség, csak a saját GPU-infra. + a naplókból tanult kollektív okosság beépül.

A kulcs: a WIBO-LOGIKA, amit most építünk (router, tool-ok, kontextus, memória, viselkedés) helyes és újrahasznosítható — a serving-infra épül köré, nem helyette. A per-user példányok együtt többet látnak, mint bárki (hálózati hatás); a naplók a self-host modell tananyaga → a kollektív okosság beépül a modellbe (aggregált, anonimizált, beleegyezéses — pénzügyi adat!).

Egy mondatban: a termék készen áll a növekedésre, az infrastruktúra a fundálandó következő fázis. Ezek ismert, megoldott mérnöki problémák — a lépcső 1-2 → 1 000 → 10 000 tervezhető és bejárható.