Sok kkv rendszere azért épül úgy, ahogy épül, mert az induláskor pontosan annyi volt elég, amennyi volt — és ez helyes döntés volt akkor. A probléma ott kezdődik, amikor a vállalkozás növekszik, de senki nem áll meg megkérdezni, vajon a rendszer bírja-e ezt a növekedést. Ez a cikk arról szól, milyen jelekre figyelj, és milyen döntéseket érdemes időben meghozni, mielőtt a növekedés magával rántja a rendszert.

A csendes teher, ami nem azonnal látszik

Egy rendszer, amit két-három felhasználóra és néhány száz rekordra terveztek, nem hirtelen omlik össze, amikor a forgalom megtízszereződik — sokkal inkább lassan, alig észrevehetően romlik. Egy lekérdezés, ami régen egy pillanat alatt válaszolt, fokozatosan lassul; egy folyamat, ami régen percek alatt lefutott, egyszer csak órákig tart; egy funkció, amit régen napi tíz alkalommal használtak, most napi ezerszer futtatva már mást igényel a háttértől. Ez a fajta lassú romlás az, amit a legkönnyebb elhalasztani — hiszen minden nap csak egy hajszálnyival rosszabb, mint az előző —, és éppen ezért az, ami a legdrágábban torlódik fel, ha senki nem figyel rá tudatosan.

A legjobb megelőzés az, ha nem várod meg, amíg a felhasználók panaszkodnak a lassúságra, hanem rendszeresen — negyedévente, félévente — visszamérsz néhány kulcsfontosságú folyamatot, és összeveted az előző méréssel. Ha egy folyamat fut ideje hat hónap alatt megduplázódott, ez egy korai figyelmeztető jel, amire még van idő reagálni, mielőtt a felhasználói élmény érdemben romlana.

A döntés, amit korán meg kell hozni: skálázhatóság vagy egyszerűség

Van egy alapvető feszültség minden rendszertervezésben: a legegyszerűbb, leggyorsabban megépíthető megoldás ritkán az, amelyik a legjobban bírja a nagy növekedést, és a legjobban skálázható megoldás jellemzően drágább és bonyolultabb, mint amire egy induló vállalkozásnak szüksége van. A jó tervezési döntés nem az, hogy mindig a legszofisztikáltabb megoldást választod „biztonság kedvéért" — ez feleslegesen drágítja és lassítja a kezdeti fejlesztést —, hanem az, hogy tudatosan választod az egyszerűbb utat, azzal a tudással, hogy hol vannak a korlátai, és mikor kell majd újragondolni.

Ez a tudatosság a kulcs: egy jó fejlesztő nem azt mondja, hogy „ez a megoldás örökre kitart", hanem azt, hogy „ez a megoldás jól szolgál majd, mondjuk, ötszázas felhasználói létszámig, azután újra kell nézni ezt a részt". Ez a fajta explicit korlát-meghatározás az, ami lehetővé teszi, hogy tervezetten, ne kapkodva érjen el hozzád a növekedés — mert tudod előre, mikor jön a következő döntési pont, nem akkor derül ki, amikor már mindenki panaszkodik.

A modularitás, ami időt vesz el most, és sokat spórol később

A leggyakoribb strukturális probléma, amivel növekvő cégek rendszereinél találkozunk, az, hogy minden minden mással szorosan összefonódik: a webshop, a raktárkezelés, a számlázás és az ügyfélkezelés úgy épült egymásba, hogy egyetlen rész módosítása is az egész rendszer átvilágítását igényli. Ez a felállás induláskor gyorsabb fejlesztést tesz lehetővé, de minden további változtatást egyre költségesebbé és kockázatosabbá tesz — egy egyszerűnek tűnő módosítás váratlan helyeken tör el valamit.

A jól szétválasztott rendszerrészek nem attól értékesek, hogy „szebb" az architektúra — attól, hogy egy csere, bővítés vagy hibajavítás egy helyen marad, nem az egész rendszert rántja magával.

A gyakorlati tanács ehhez nem az, hogy induláskor mindent szétválassz mesterségesen bonyolult rendszerré — ez feleslegesen lassítaná az elindulást. Inkább arról van szó, hogy amikor a rendszer már él és növekszik, tudatosan figyeld, mely részek azok, amik a leggyakrabban változnak, vagy amiket a legszívesebben cserélnél le egy jobb megoldásra — és ezeket a részeket válasszad szét a többitől elsőként, mielőtt a köztük lévő összefonódás annyira megnő, hogy a szétválasztás maga is egy komoly, kockázatos projektté válik.

Ha úgy érzed, a rendszereitek egyre nehezebben bírják a növekedést, nézzük át együtt az architektúrát — megmondjuk, mi az, ami még évekig kitart, és mi az, amire hamarosan érdemes figyelni.