virtuális várószoba

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.

Ha nagyon monolitikus a cucc, akkor még az jutott eszembe, amit kurva rég csináltam egyszer, hogy elé lehet tenni egy (felhős) proxy-t, ami sticky session alapokon a forgalom egy adott százalékát átküldi egy "sorry szerverre", hogy túlterheltség miatt próbálja újra x perc múlva és a session cookie - ami a sticky - x perc múlva jár le, utána kap újra random lehetőséget, hogy bejut vagy újra megy a "sorry szerverre". A proxy-t pedig a cucc terheltségének függvényében paraméterezed real-time.

blekkfrájdéj webshopok felkészülnek :D