virtuális várószoba

Sziasztok!

 

A https://hup.hu/node/186624 téma folyamányaként mint B terv, beüzemelnénk valami felhős waitingroomot biztos ami biztos alapon.

 

Eddig ezt a kettőt néztem:

https://developers.cloudflare.com/waiting-room/

https://aws.amazon.com/solutions/implementations/virtual-waiting-room-o…

 

A cloudflare-t egyszerűbbnek látszik beüzemelni.

 

Mit ajánlanátok?

 

Köszi!

Hozzászólások

Szerkesztve: 2024. 10. 25., p – 10:54

A Cloudflare megoldásához kell, hogy betedd a szolgáltatást a CDN mögé, ami magával hozza a statikus tartalom cachelését házon kívül, így nagyjából okafogyottá válik a történet.

Nem teljesen értem a dolgot, szerintem valamit rosszul közelítesz meg.

Remélhetőleg a frontend és a backend kód a külön életet él, és csak valamilyen API-n keresztül beszélnek egymással, ha nem, akkor ez egy elbaszás és nagyon sok lehetőséged nincs megjavítani azon kívül, hogy valamilyen szinten szétválasztod.

Ha a frontend kvázi statikus kód, ki lehet tenni CDN-re, aztán fire-and-forget. A backend-re kell koncentrálni, ha az nem skálázható - és gondolom ez (is) a gond, akkor be kell tenni az API flow-ba aszinkron dolgot, vagyis legyen valahol egy API szerver, skálázható (tipikusan AWS lambda és társai), az beleteszi egy queue-ba a kérést és a backend veszi ki onnan, szolgálja ki és válaszol vissza, így a backend sose fog összeomlani, mert önmaga határozza meg, hogy milyen gyorsan veszi ki a queue-ból a kéréseket. A kliensek meg megvárják a választ és a queue mélysége megmondja, hogy mennyit kell átlagosan várniuk.

Alapvetően így is érdemes tervezni az architektúrát, ha nem lehet a backend-et is korlátlanul skálázni.

Értem, de ha architekturális elbaszás van, azt nem tudod architekturális változások nélkül megoldani... ha a CDN kivitelezhető, akkor úgyis megoldódik a problémák nagy része, ha a CDN se megy, akkor meg marad az elbaszás és nem nagyon van mozgástered.