Egy közösségi programokat szervező csapat weboldala elsőre egyszerű feladatnak tűnhet: programok, időpontok, helyszínek, néhány fotógaléria. Aztán jönnek a felhasználók, a közösségi funkciók, az automatizmusok, a jogosultságkezelési szabályok, külső szolgáltatások és a milliós adatbázis táblákat használó weboldalra érkező sokezer látogató.
Egy ilyen közösségi eseményplatformot több mint tíz éve fejlesztünk, az első sortól kezdve, az ötletgazdával közösen kitalálva a funkciókat.
A nehézséget az összefüggések adják
A platform eredetileg programok, események és bulik népszerűsítésére készült, de a regisztrált felhasználók egymással is kapcsolatba léphetnek rajta. Az események adatai nagyon részletesen megadhatók: van oldalon belüli visszajelzés a részvételről, ehhez kötött, csak a jelentkezőknek látható jegyvásárlási lehetőség, létszámkorlát, kísérők, „mit hozz magaddal” lista és kommentfal. Az eseményekhez utólag galériák és emlékek kapcsolódnak, a felhasználók csoportokba léphetnek, és a rendszer saját hírlevélküldővel célzottan tud nekik írni.
Ezek külön-külön nem bonyolult funkciók. A nehézség abból adódik, hogy mind összefügg: egy esemény láthatósága függ a szervezőtől, a csoporttagságtól és a felhasználók közötti kapcsolatoktól, egy létszámkorlát a jelentkezésekre és a jegyvásárlásra is hat. A jogosultságkezelés, vagyis hogy ki kit lát, és kiből mit láthat, a rendszer egyik legösszetettebb része lett.
Az adatmodell idővel visszaszól
Ami néhány ezer rekordnál jól működik, az milliós nagyságrendnél már nem biztos. Az adatbázisnak voltak olyan időszakai, amikor a komplex lekérdezések nagy terhelést okoztak. Ilyenkor nem egy nagy újraírás hozta a megoldást, hanem folyamatos optimalizáció: ahol indokolt volt, denormalizáltuk az adatokat, és előre kiszámolt adatnézeteket vezettünk be, hogy a gyakran olvasott információt ne kelljen minden kérésnél újra összerakni.
A munka egyik legérdekesebb része az adatbázis-struktúra tervezése mellett az időzített háttérfolyamatok kialakítása volt. Az események a meghirdetéstől a lezárásig maguktól váltanak állapotot, és ennek akkor is megbízhatóan kell működnie, ha éppen senki nem figyel rá.
Tíz év, több modernizációs kör
A platform Symfony-alapú, egyedi fejlesztés. Tíz év alatt több modernizációs kört hajtottunk végre, és a külső függőségek legalább harmada lecserélődött. Egy ilyen csere ritkán egyszerű verziófrissítés: egy felhasználókezelő vagy levélküldő komponens kiváltása a rendszer sok pontját érinti. Közben a külső szolgáltatások, például a közösségimédia-kapcsolatok API-jai is változnak, és ezeket le kell követni.
A nagy felhasználószámú, nyilvános platformok a támadóknak is vonzó célpontok. Kezelni kellett túlterheléses támadásokat, fiókfeltörési kísérleteket, valamint az adatok automatizált begyűjtésére és a sérülékenységek felderítésére irányuló próbálkozásokat is.
Közben a rendszernek működnie kell
Egy élő közösségi platformot nem lehet bezárni néhány hónapra, amíg rendbe tesszük. A fejlesztés és az üzemeltetés párhuzamosan zajlik: új funkciók készülnek, apró hibák kerülnek elő, és a modernizációt úgy kell végezni, hogy a felhasználók közben zavartalanul használhassák az oldalt.
Mit csinálnánk ma másképp?
Tíz év megtanít dolgokra. Ma kevesebb, modulokon átívelő függőséget terveznénk, és a komplexitást igyekeznénk egy-egy modul határain belül tartani, hogy később önállóan lehessen átalakítani. A jogosultságkezelés jó példa erre: ma talán egyszerűbbre terveznénk, mert a rugalmassága idővel a továbbfejlesztés költségében is megjelent.
És közben az üzleti igény is változik
Egy éveken keresztül működő platformnál az üzleti igények folyamatosan változnak. A példában a felhasználói élmény súlypontja egyre inkább a mobil felé tolódik, a weboldal szerepe is átalakul, a mögötte álló rendszernek pedig ehhez is alkalmazkodnia kell.
Kicsiben indulni könnyű
Az Eneoptnál olyan rendszereket építünk, amelyeknek évek múlva is alkalmazkodni képesek ahhoz, amit kiszolgálnak. Ha a te weboldalad is kezdi kinőni a kereteit, mert egyre több a felhasználó, a funkció és az összefüggés, beszéljünk, mielőtt az adatmodell visszaszól. Kicsiben indulni könnyű. Nagyra nőni és közben működőképesnek maradni: ez az érdekes rész.