KyllC$, ehdottomasti! TC$mC$ on itse asiassa yksi hajautettujen P2P- ja
mesh-verkkojen tyypillisimmistC$ ja mielenkiintoisimmista ominaisuuksista. Kun
siirrytC$C$n perinteisestC$ keskitetystC$ HTTP-palvelimesta asynkronisten
protokollien ja mikropalveluverkkojen (kuten OMEGA Dark Mesh) maailmaan,
verkossa voi hyvinkin olla useita reitittimiC$ tai solmuja, jotka kaikki
kokevat olevansa oikeita tahoja vastaamaan huutoon.

Se, mitC$ silloin tapahtuu, riippuu tC$ysin siitC$, millC$ protokollakerroksell
a asiaa katsotaan. TC$ssC$ tapauksessa meidC$n on erotettava toisistaan
selaimen kC$yttC6liittymC$ ja taustalla jyllC$C$vC$ verkko.

### 1. Nykyinen tilanne: "Nopein voittaa" (Race Condition)

Koska virtualisoimme verkon selaimen Service Workerissa kC$yttC$en standardia
`fetch`-rajapintaa, olemme sidoksissa JavaScriptin **Promise**-arkkitehtuuriin.

* Promise voi ratketa (resolve) tasan **yhden kerran**.
* Kun kirjoitat `mesh /login`, jC$rjestelmC$ lC$hettC$C$ pyynnC6n Gatewayn yli
verkkoon ja jC$C$ odottamaan.
* Jos Backend A ja Backend B vastaavat molemmat, Gateway puskee molemmat
vastaukset wss-putkea pitkin takaisin Service Workerille.
* Service Worker ottaa ensimmC$isenC$ saapuvan vastauksen (esim. Backend A) ja
ratkaisee Promisen. Vastaus pC$C$tyy komentorivisi `$LAST` -muuttujaan.
* Kun Backend B:n vastaus saapuu millisekuntia myC6hemmin, selain huomaa,
ettC$ kyseisen pyynnC6n Promise on jo ratkaistu. Vastaus kC$ytC$nnC6ssC$
putoaa tyhjyyteen (tai tuottaa piilotetun virheilmoituksen Service Workerin
uumeniin), koska HTTP-protokollan semantiikka ei salli kahta vastausta yhteen
pyyntC6C6n.

TC$mC$ on usein jopa toivottava ominaisuus (esim. hajautettu Load Balancing /
Anycast), jos molemmat backendid sisC$ltC$vC$t saman datan. Nopein solmu
palvelee kC$yttC$jC$n.

### 2. EntC$ jos data on erilaista ja halutaan talteen?

Jos molemmilla backendeillC$ on arvokasta, toisistaan poikkeavaa dataa (esim.
toinen on tietokannan replika, joka on hieman jC$ljessC$), meidC$n pitC$C$
rikkoa perinteisen HTTP:n illuusio ja siirtyC$ todelliseen asynkroniseen
hajautettuun malliin.

TC$hC$n on pari eleganttia arkkitehtuurillista ratkaisua, joita voit
hyC6dyntC$C$:

* **Tapahtumavirta (Event Sourcing / Pub-Sub):** Sen sijaan, ettC$ `mesh
/query` tekisi standardin POST-kutsun, se voisi avata tietovirran (esim.
matkimalla Server-Sent Events -striimiC$ tai kC$yttC$mC$llC$ aiemmin ideoitua
infinite-stream Ghost Proxya). TC$llC6in komentoriviprosessi ei katkea
ensimmC$iseen vastaukseen, vaan jokainen verkosta valuva uusi JSON-vastaus
tyC6nnetC$C$n vuorollaan `_STACK`-pinoon.
* **CRDT (Conflict-free Replicated Data Type) / Aggregaatio Gatewaylla:**
Annetaan Gateway-reitittimen hoitaa likainen tyC6. Kun Gateway lC$hettC$C$
kyselyn Dark Meshiin, se ei vastaa selaimelle heti ensimmC$isen osuman
saatuaan. Se avaa esim. 50 millisekunnin ikkunan, kerC$C$ kaikki saapuvat
vastaukset eri backendeiltC$, yhdistC$C$ (merge) niiden tilan
konfliktivapaasti yhdeksi master-JSONiksi ja palauttaa sen yhtenC$ pakettina
selaimen `fetch`-kutsulle.

Miten haluaisit verkkosi kC$sittelevC$n nC$itC$ tilanteita  riittC$C$kC6
toistaiseksi yksinkertainen nopeimman solmun priorisointi, vai pitC$isikC6
meidC$n alkaa suunnitella Service Workeriin tukea monivastausten puskuroidulle
yhdistC$miselle?