TC$mC$ on kerrassaan loistava ja arkkitehtonisesti erittC$in kypsC$ suunta.
Kun rakennetaan todella vikasietoista, hajautettua verkkoa, kaikkein
kestC$vimmC$t vastaukset lC6ytyvC$t lC$hes poikkeuksetta tietotekniikan
alkulC$hteiltC$  ajalta ennen jatkuvasti auki olevia TCP/IP-yhteyksiC$,
jolloin verkot olivat hitaita, epC$luotettavia ja dataa siirrettiin
magneettinauhoilla (Sneakernet).

TC$ssC$ on katsaus siihen, miten 1970-luvun mainframe- ja varhaiset
UNIX-konseptit vastaavat tC$ydellisesti tC$hC$n tarpeeseen, ja kuinka voimme
modernisoida ne saumattomaksi osaksi suunnittelemaamme hakemistopohjaista
arkkitehtuuria.

### 1. Historialliset konseptit taustalla

**Store-and-Forward ja Spooling (UUCP, 1979)**
Ennen internetiC$ UNIX-koneet keskustelivat keskenC$C$n UUCP (Unix-to-Unix
Copy) -protokollalla. Se perustui tC$ysin offline-ajatteluun. JC$rjestelmC$
pudotti viestin `/var/spool/` -hakemistoon. Erillinen demoni soitti kerran
yC6ssC$ modeemilla toiseen koneeseen ja siirsi tiedostot. Tietokanta/sovellus
ei tiennyt verkosta mitC$C$n; se vain luki ja kirjoitti paikallista
tiedostojC$rjestelmC$C$.

**Magneettinauhojen Header/Trailer -merkit (ANSI X3.27, 1970-luku)**
Kun siirrettiin gigatavujen eriC$ dataa fyysisillC$ nauhoilla, nauha saattoi
katketa tai lukija vikaantua. TC$mC$n estC$miseksi kehitettiin standardi, joka
on tC$smC$lleen ehdottamasi "kC$ttely":

1. **HDR1 (Header Label):** Kertoo kuka lC$hetti, mitC$ on tulossa ja mikC$ on
blokin ID.
2. **Data (Payload):** Itse massiivinen, mahdollisesti satojen gigatavujen
erC$ajo.
3. **EOF1 (End of File / Trailer):** Vahvistus siitC$, ettC$ data on loppu ja
ehjC$. Vasta tC$mC$n lukemisen jC$lkeen data hyvC$ksyttiin.

**EDI (Electronic Data Interchange)**
Kaupan alan standardi, jossa kaikki viestit pakataan tiukkaan "kirjekuoreen"
(Envelope). Kirjekuori sisC$ltC$C$ globaalit lC$hettC$jC$/vastaanottaja-ID:t
(esim. GLN-koodit), ja vasta kuoren sisC$llC$ on viittaus varsinaiseen
raskaaseen hyC6tykuormaan.

---

### 2. Moderni Mailbox-arkkitehtuuri (IN/OUT Staging)

YhdistC$mC$llC$ nC$mC$ 50 vuotta vanhat opit aiemmin rakentamiimme
`CAS_BLOB_STORE`- ja `SIGNAL_MESH` -konsepteihin, saamme aikaan
tuhoutumattoman, agnostisen viestintC$vC$ylC$n.

Luodaan solmuille uusi tiedostorakenne:
`/mnt/zfs-db/spool/outbox/` (LC$htevC$t)
`/mnt/zfs-db/spool/inbox/` (Saapuvat)

Koska siirtokerros (Transport) voi olla mitC$ tahansa  rsync, fyysinen
USB-levy drone-lennokissa, tai asynkroninen viestijono  tietokanta operoi vain
nC$issC$ kansioissa tapahtuvilla atomisilla tiedosto-operaatioilla.

#### 3-Vaiheinen KC$ttely (TiedostojC$rjestelmC$tasolla)

Oletetaan, ettC$ solmu `NODE-A` haluaa lC$hettC$C$ gigatavun erC$ajon solmulle
`NODE-B`. Viestin ID on Base62-enkoodattu `Msg7xZ9Q`.

**Vaihe 1: Aloitus (Meta-Envelope)**
LC$hettC$jC$ luo JSON/tekstimuotoisen kirjekuoren ja tallentaa sen nimellC$
`Msg7xZ9Q.meta.start`.

```json
{
  "msg_id": "Msg7xZ9Q",
  "sender_id": "GLOBAL-NODE-A-991",
  "receiver_id": "GLOBAL-NODE-B-442",
  "intent": "BATCH_INSERT",
  "expected_blob_hash": "a1b2c3d4...",
  "timestamp": 1700000000
}

```

*Transport-koneisto huomaa tiedoston ja kopioi sen hitaasti verkon (tai
muistitikun) yli vastaanottajan INBOXiin. Vastaanottajan tietokanta lukee
tC$mC$n, toteaa "Okei, tC$llainen massiivinen operaatio on alkamassa", ja
varautuu.*

**Vaihe 2: MC6hkC$le (Payload)**
SiirretC$C$n varsinainen gigatavujen data `Msg7xZ9Q.blob`.
*TC$mC$ on tC$ysin erillinen tiedosto. SitC$ saatetaan siirtC$C$ pC$tkissC$
tuntien ajan heikon satelliittiyhteyden yli. Vastaanottava tietokanta nC$kee
`.blob` -tiedoston kasvavan, mutta ei koske siihen, koska viimeistelyviesti
puuttuu.*

**Vaihe 3: Viimeistely (Trailer/Commit)**
Kun siirtokerros tietC$C$, ettC$ `.blob` on siirretty 100 % onnistuneesti, se
luo (tai siirtC$C$) lopetusviestin `Msg7xZ9Q.meta.end`.
*TC$mC$ on puhdas, tyhjC$ signaalitiedosto (vastaa aiemmin rakentamaasi
`touch`-triggeriC$). Heti kun vastaanottava tietokanta (Dispatcher/Orchestrator
) nC$kee `.meta.end` -tiedoston ilmestyvC$n INBOXiin, se laskee `.blob`
-tiedoston tiivisteen, vertaa sitC$ `.meta.start` -tiedoston odotukseen, ja
lukitsee viestin prosessointiin siirtC$mC$llC$ ne tyC6tilaan.*

---

### 3. Miksi tC$mC$ ratkaisee ongelmasi?

* **TC$ydellinen Agnostisuus:** Tietokantamoottorisi (C-ydin ja Proxy) ei
tarvitse tietC$C$ pC$tkC$C$kC$C$n siitC$, onko internet olemassa. Se lukee
INBOXia ja kirjoittaa OUTBOXia. Siirtokerroksen insinC6C6rit voivat rakentaa
siihen vC$liin mitC$ tahansa satelliittilinkeistC$ postin kuljettamiin
kiintolevyihin.
* **Ei Timeout-ongelmia (Lock-Free):** Yleisin ongelma moderneissa REST/gRPC
-rajapinnoissa on yhteyden katkeaminen kesken pitkC$n siirron. TC$ssC$
arkkitehtuurissa vastaanottaja ei lukitse resursseja odottaessaan dataa; se
reagoi vasta kun `.meta.end` on levyllC$.
* **Helppo roskienkeruu (Garbage Collection):** Jos INBOXissa lojuu
`.meta.start` ja `.blob`, mutta `.meta.end` -tiedostoa ei kuulu viikkoon,
riippumaton taustasC$ie (vastaava kuin aiempi `LAZY_GC`) voi tyhjentC$C$ orvot
tiedostot pois siististi.

MiltC$ tC$llainen "spool-hakemistoihin" perustuva, tiedostojC$rjestelmC$n
lukoilla toimiva INBOX/OUTBOX -malli kuulostaisi, ja pitC$isikC6 meidC$n
miettiC$, kuinka tC$mC$ konkreettisesti liitetC$C$n aiemmin suunniteltuun
erC$ajojen (batch) staging-alueeseen Proxy-kerroksessa?