NC$mC$ luvut ovat kertaikkiaan loistavia! Yli 1700 riviC$ sekunnissa saattaa
kuulostaa nykymittapuulla peruskauralta, mutta tC$ssC$ kontekstissa se on
arkkitehtoninen riemuvoitto.

TC$ssC$ on syy, miksi tuo tulos on todellisuudessa poikkeuksellisen kova:

### Suorituskyvyn anatomia

* **Synkroninen rajoite:** Koodasimme Python-tuontityC6kalun tC$ysin
synkroniseksi. Skripti lC$hettC$C$ yhden HTTP-pyynnC6n, odottaa siihen
vastauksen, ja vasta sitten lC$hettC$C$ seuraavan. Keskinopeus 1740 riviC$/s
tarkoittaa, ettC$ yhden rivin *kokonaislatenssi* edestakaisin on keskimC$C$rin
vain **0,57 millisekuntia**.
* **Putken tehokkuus:** Tuon puolen millisekunnin aikana Proxy-kerros ehtii
purkaa JSONin, validoida datan, laskea 32-tavuisen hashin raskaalle
tekstidatalle, tallentaa tekstin ZFS:lle CAS-varastoon, pakata jC$ljelle
jC$C$vC$n metriikan binC$C$riksi ja lC$hettC$C$ sen TCP-portin yli C-ytimelle.
* **C-ytimen nopeus:** C-moottori ottaa binC$C$rin vastaan ja siirtC$C$ sen
atomisesti Lock-Free -rengaspuskuriinsa. Muistioperaatio on niin kevyt, ettei
se nC$y viiveenC$ kC$ytC$nnC6ssC$ lainkaan.

Jos muuttaisit tuon `csv_importer.py` -skriptin kC$yttC$mC$C$n
monisC$ikeisyyttC$ tai `asyncio`-kirjastoa (jolloin pyyntC6jC$ ammutaan
rinnakkain tuhansittain), iskisitte nopeasti kymmenien tuhansien rivien
sekuntivauhtiin.

### Seuraava askel: Vikasietoisuus (INTENT_BUFFER)

Nyt kun nopeus ja CRUD-putki on todistettu saumattomaksi, on tC$ydellinen
hetki tarttua aiemmin listattuun `INTENT_BUFFER {db-proxy-0002}`
-komponenttiin. TC$mC$ on ominaisuus, joka erottaa leluprojektit oikeista,
tuotantovalmiista hajautetuista jC$rjestelmistC$.

Tavoitteena on varmistaa, ettC$ jos C-ydin kaatuu, pC$ivitetC$C$n tai
irrotetaan huollon ajaksi, Mesh-verkosta satava data ei katoa bittiavaruuteen,
eikC$ asiakas saa 500 Internal Server Error -ilmoituksia.

**Vaihtoehdot INTENT_BUFFERIN toteutukseen:**

1. **In-Memory Queue (Kevyt):** Proxy yllC$pitC$C$ RAM-muistissaan jonoa
(esim. `asyncio.Queue`). Jos C-yhteyttC$ ei saada, data jC$C$ jonoon ja
tallentuu heti, kun TCP-portti taas vastaa. *Riski: Jos itse Proxy kaatuu,
jonossa oleva data menetetC$C$n.*
2. **Write-Ahead Log (WAL) levyllC$ (Robust):** Ennen kuin Proxy edes
yrittC$C$ lC$hettC$C$ dataa C-ytimelle, se kirjoittaa intentiot (komennot)
raakana nopeaan, lokaaliin Append-Only -tekstitiedostoon (tai jopa kevyeen
lokaaliin SQLite-kantaan). Jos Proxy tai C-ydin kaatuu, kC$ynnistyksen
yhteydessC$ Proxy lukee lokin ja "toistaa" (replay) kaikki siellC$ olevat
kC$sittelemC$ttC6mC$t intentiot C-moottorille.

Kumpaan suuntaan haluaisit viedC$ Proxyn puskurointia: rakennetaanko
maksimaalisen nopeuden in-memory jono, vai tC$ydellisen vikasietoisuuden
takaava levy-backed intentioloki?