Sokszor olvassuk, hogy jól kell kiválasztani az induló webshopunkat, hogy amikor a terhelés nő, tudjunk skálázni. Azt is mondják, hogy nem akkor kell váltani, amikor baj van, hanem amikor a terhelés eléri a relatív magas szintet. De vajon ezt hogyan veszi észre a webshop tulajdonosa? Milyen árulkodó jelek vannak, amik azért kiáltanak: válts?

Egy webshop hosszabb ideig működhet látszólag stabilan, majd egy ponton hirtelen elkezd „szétesni”: lassul, hibázik, csúnyán öregszik, elérte a határait. Amíg a forgalom alacsony, nem tűnik fel, és az olyan időzített bombák, mint a szinkron folyamatok, manualitásra épülő részfolyamatok, pluginokra épülő logika, nem okoznak gondot. Amikor nő a rendelési szám, ezek a kompromisszumok végül elkezdenek elviselhetetlenné válni. Ilyenkor jelennek meg azok a tünetek, amelyeket sokszor „teljesítményproblémának” gondolnak, valójában azonban architekturális problémák.

De vajon honnan látjuk, hogy optimalizálni kell, vagy „szintet lépni”? 

Az egyik ilyen eset, ami változásért kiált, amikor a backend folyamatok nem tudnak lépést tartani a beérkező eseményekkel. Egy rendelés ugyanis több műveletet indít el: fizetés feldolgozása, számlázás, készlet frissítése, értesítések küldése. Ha ezek szinkron módon, egymás után történnek, akkor minden egyes rendelés ideje összeadódik. Kevés rendelésnél oké, de soknál már torlódás lesz. Az aszinkron feldolgozás azt jelenti, hogy a kritikus útvonalon (például rendelés létrejötte) csak a minimálisan szükséges lépések történnek meg, a többi feladat pedig háttérfolyamatként fut le. 

Lehet más út is: az event-sourcing során például, amikor a rendszer állapotán változtatást végzünk, ezt a változást eseményként rögzítjük, és az események újrafeldolgozásával bármikor, a jövőben is képesek vagyunk a rendszer teljes állapotát rekonstruálni. Az eseményfeldolgozásnak tehát nem feltétlenül kell aszinkronnak lennie, egy webshop event-sourcingot is használhat.

A növekedés másik kritikus pontja az adatkezelés. Kezdetben egy webshop gyakran egyetlen adatbázisra épül. Ez egyszerű és hatékony, amíg az adatmennyiség és a lekérdezések száma alacsony. Idővel azonban az adatbázis válik a szűk keresztmetszetté, ilyenkor már nem elegendő „erősebb szervert” használni, hanem át kell gondolni az adatok szervezését: indexelés, read replica-k (másolatok), vagy bizonyos esetekben az adatok szétválasztása külön szolgáltatások között.

Ezzel párhuzamosan az alkalmazás is eléri a határait. A legtöbb induló webshop monolitikus felépítésű: minden funkció egyetlen rendszerben található. Egy kisebb módosítás is az egész rendszert érintheti, a hibák hatása nehezen izolálható, és a skálázás is csak a teljes alkalmazás egészének szintjén lehetséges. A kritikus részeket (például fizetés, rendeléskezelés) érdemes leválasztani.

A szintlépés tehát nem egyetlen döntés, hanem több egymásra épülő változtatás sorozata. A „nagyobb szerver”, „még egy plugin”, „gyors javítás” nem megoldás hosszú távon, a fentieket végiggondolva azonban megértjük, hol van a szűk keresztmetszetünk.