Salutare tuturor. Am ajuns într-un punct în care monolitul clasic pe un singur dedicat începe să devină o problemă de business, nu neapărat de resurse.
Avem o aplicație de tip SaaS cu vreo 11k utilizatori activi zilnic, scrisă în Node.js cu PostgreSQL și un Redis local pentru cache. Până acum, totul a rulat impecabil pe o singură mașină Hetzner cu 64 GB RAM. Doar că fondatorii au prins o finanțare, au contractat clienți enterprise și cerința fermă de la ei este eliminarea punctului unic de cădere: vor minim 3 servere de aplicație în spatele unui load balancer, iar baza de date separată.
N-am mai făcut o astfel de migrare de la zero pe un sistem live cu clienți plătitori. Teoria o știu toată, dar diavolul stă în detalii și aș vrea să validez ordinea pașilor cu cei care au trecut deja prin asta.
1. Fișierele locale și sesiunile: prima groapă
Prima capcană pe care am identificat-o este stocarea. În prezent, utilizatorii urcă PDF-uri și poze de profil direct pe disc, într-un folder montat local. Evident, dacă pun 3 noduri web, fișierul urcat pe Nodul A nu va exista pe Nodul B.
Aici dilema mea este de cost vs. complexitate. Să trec totul pe S3 (sau un compatibil gen Cloudflare R2 / Backblaze B2) înainte să mă ating de load balancer? Trade-off-ul e clar: pe S3 adaug o latență de rețea la fiecare upload și modific ceva cod moștenit, dar mă scap de nebunia unui disc partajat prin NFS, care din experiențele altora crapă la I/O când ți-e lumea mai dragă.
La sesiuni presupun că suntem acoperiți: rulăm JWT-uri semnate fără state în memorie, iar datele volatile sunt deja împinse într-un Redis dedicat. Dacă mă înșel și e nevoie de sticky sessions la nivel de load balancer, lăsați un semn.
2. Baza de date și limita de conexiuni: intră PgBouncer
În clipa în care am 3 instanțe ale aplicației, pool-ul de conexiuni către Postgres se triplează. Dacă fiecare instanță pornește cu 50 de conexiuni în pool, ajung rapid la 150 de procese backend pe Postgres. La un proiect anterior pe Postgres 14, pe la 300 de conexiuni deschise am observat o creștere de 35% a latenței doar din overhead-ul de context switching.
Planul meu este să pun PgBouncer pe nodul separat de DB. Întrebarea este: să merg direct pe transaction pooling? Știu că pierzi LISTEN/NOTIFY și prepared statements în anumite drivere de Node (folosim Prisma și câteva raw queries prin pg). A meritat bătaia de cap cu rescrisul query-urilor dependente de sesiune sau ați lăsat session pooling la început?
3. Load Balancer hardware/cloud vs Nginx propriu
Nu știu dacă merită să configurez eu un nod dedicat de HAProxy/Nginx sau să merg direct pe Load Balancer-ul gestionat de la furnizor (Hetzner Load Balancer costă câțiva euro pe lună și include SSL termination automat). În fața lui aș lăsa oricum Cloudflare pentru protecție DDoS, SSL la margine și cache pe asset-uri statice.
Îngrijorarea mea e legată de deploiamente: cum gestionați zero-downtime fără să vă complicați cu Kubernetes? Dacă aveți un script simplu de tipul scos serverul din target pool, rulați git pull + reload, băgat la loc, cât de stabil e în producție?
Cum ați prioritiza voi etapele astea ca să nu riscăm blocaje în baza de date sau imagini lipsă după migrare?