Flux sezonier de rezervari

Clientul, o retea de pensiuni din zona montana, se confrunta in fiecare vara cu acelasi tip de problema: serverul care tine aplicatia de rezervari intra in suprasarcina exact in weekendurile cu cerere mare. Apelurile de suport ajungeau la noi dupa ce pagina devenea lenta sau, mai rau, dupa ce o rezervare se pierdea la jumatatea procesului de plata.

Am inceput prin a pune monitorizare pe cele trei masini virtuale care ruleaza aplicatia si baza de date. Timp de doua saptamani am strans date despre utilizarea CPU, memorie si latenta interogarilor. A devenit clar ca varful nu era la ora pranzului, cum presupunea administratorul intern, ci seara, intre 20:00 si 23:00, cand oamenii planificau concediile de pe telefon.

Decizia practica a fost sa mutam instanta principala pe un plan cu mai mult RAM si sa separam baza de date de serverul web. Apoi am configurat un al doilea nod pentru citiri, astfel incat paginile cu lista de camere disponibile sa nu mai concureze cu scrierile din timpul unei rezervari. Am adaugat si un cache pentru cererile frecvente, care a redus numarul de interogari repetate cu aproximativ 40%.

Partea mai putin spectaculoasa, dar la fel de importanta, a fost disciplina operationala. Am stabilit un proces clar pentru ferestrele de mentenanta: orice actualizare de securitate se aplica martea dimineata, niciodata vineri dupa-amiaza. Am documentat procedura de rollback si am testat-o de doua ori inainte de sezonul de varf. Backup-urile automate ruleaza acum la fiecare sase ore, cu o copie suplimentara trimisa offsite.

Dupa doua luni de functionare in conditii reale, clientul a raportat zero incidente majore in timpul weekendurilor aglomerate. Timpul mediu de raspuns al paginii a scazut de la 4,2 secunde la aproximativ 1,1 secunde. Nu am promis ca totul va fi perfect, dar am livrat un sistem care rezista la varf si un set de proceduri care elimina ghicitul din operatiunile zilnice.