Salutare tuturor. Am dat recent peste o problemă destul de dubioasă la o aplicație cu vreo 12.000 de useri activi: oamenii erau delogați din senin după doar 5 minute de inactivitate. Partea ciudată era că în DevTools, cookie-ul de sesiune (connect.sid sau ce folosiți voi) era setat corect, cu un Expires de peste 30 de zile în viitor.
Dacă ai pățit asta sau treci acum prin ea, hai să-ți arăt unde se rupe filmul de obicei. Nu e magie neagră, e doar arhitectură care nu se pupă cu realitatea din producție.
1. Iluzia din browser: Cookie-ul e doar o cheie, nu ușa
Cea mai comună greșeală pe care o văd (și am făcut-o și eu la începuturi) este să confundăm durata de viață a cookie-ului cu durata de viață a sesiunii pe server. Cookie-ul este doar un ID, un bilet de ordine. Dacă serverul decide să șteargă datele asociate acelui ID, poți să ai tu cookie valabil până în 2050, că tot la pagina de login ajungi.
La proiectul de care vă ziceam, rulam pe un stack Node.js cu Express și express-session. În cod aveam frumos definit un maxAge generos. Totul părea perfect în local.
Problema în producție? Serverul folosea managerul de sesiuni default, care ține totul în memorie (MemoryStore). La fiecare deploy automat sau când containerul de Docker își lua restart din cauza unui memory leak minor, memoria se ștergea complet. Sesiunile mureau instantaneu.
Trade-off-ul aici: MemoryStore e super rapid pentru dezvoltare locală și nu necesită configurare, dar e o catastrofă absolută în producție. Trecerea la Redis a rezolvat problema asta, dar a adăugat un cost suplimentar de infrastructură și mentenanță.
2. Capcana din spatele Load Balancer-ului
Dacă ai mai mult de o instanță de server (de exemplu, ești pe Kubernetes sau ai un cluster cu PM2), ai nevoie de stickiness sau de o bază de date comună pentru sesiuni.
Am pățit-o pe AWS cu un Application Load Balancer. Userul trimitea request-ul de login, ajungea pe Instanța A, care îi crea sesiunea în memoria ei locală. La următorul click, după 5 minute, load balancer-ul îl trimitea pe Instanța B, fiindcă era mai liberă. Instanța B nu știa cine e userul, așa că îi dădea eject direct la login.
Soluția curată? Sesiuni centralizate în Redis sau Memcached. Soluția rapidă și un pic mai "murdară"? Sticky sessions active pe load balancer. Merge bine dacă ai trafic mic spre mediu, dar e nasol pentru scalare uniformă.
3. Curățenia de primăvară (Garbage Collection) din PHP sau Redis
Dacă folosești PHP, ai celebrul session.gc_maxlifetime în php.ini. Chiar dacă tu setezi cookie-ul din cod pe 30 de zile, dacă configurarea serverului are valoarea default de 1440 de secunde (adică 24 de minute), PHP va șterge fișierele de sesiune de pe disc după acele 24 de minute de inactivitate.
La fel și în Redis. Dacă ai setat un TTL (Time To Live) greșit la nivel de cheie sau dacă Redis-ul tău rulează cu o politică de evacuare agresivă (cum ar fi volatile-lru) pentru că a rămas fără memorie, va începe să șteargă sesiunile utilizatorilor inactivi ca să facă loc la date noi. Am economisit vreo 30% din memoria pe Redis doar optimizând ce salvam în sesiune: țineam ditamai obiectul de user serializat, în loc de un simplu ID.
Voi cum ați rezolvat problemele astea de sync între client și server? Ați avut cazuri unde de vină era vreun proxy intermediar sau Cloudflare?