Estimările back-of-the-envelope sunt fundamentale în System Design deoarece te ajută să iei decizii arhitecturale rapide, înainte de a intra în detalii complexe de implementare. În practică, acest abilitate îți permite să validezi dacă o idee este fezabilă tehnic și economic, evitând pierderea timpului pe soluții imposibil de scalat. Un inginer capabil să facă aceste calcule mentale demonstrează maturitate tehnică și înțelegerea profundă a constrângerilor sistemelor distribuite.
Concepte cheie
- Unități de măsură standard: Folosește unități comune precum QPS (queries per second), GB (gigabytes) sau ms (milisecunde) pentru a menține consistența calculelor.
- Latența vs. Throughput: Latența este timpul necesar pentru un singur request, în timp ce throughput-ul este numărul total de request-uri procesate într-o unitate de timp.
- Capacitatea stocării: Calculează spațiul necesar bazat pe volumul de date zilnic/lunar și rata de retenție (cât timp păstrezi datele).
- Bandwidth-ul de rețea: Estimează traficul de ieșire/ieșire în funcție de dimensiunea medie a payload-ului și numărul de utilizatori activi.
- Costurile infrastructurii: Transformă estimările tehnice în costuri financiare aproximative pentru a evalua viabilitatea business-ului.
- Factori de siguranță (Headroom): Adaugă întotdeauna un buffer (de obicei 2x-5x) pentru vârfuri de trafic neașteptate sau creșteri sezoniere.
- Legile lui Amdahl și Little: Utilizează aceste principii matematice simple pentru a estima timpii de așteptare și capacitatea cozilor de așteptare.
Exemplu practic
Să presupunem că trebuie să proiectezi un sistem de notificări push pentru o aplicație cu 1 milion de utilizatori activi zilnic (DAU).
- Calcul volum: Dacă 10% dintre utilizori primesc o notificare pe zi, avem 100.000 notificări/zi.
- Distribuție temporală: Traficul nu este uniform. Presupunem un factor de vârf de 10x față de media orară. Media orară = 100.000 / 24 ≈ 4.166. Trafic vârf ≈ 41.660 notificări/oră, adică ~11 notificări/secundă.
- Concluzie: Un singur server simplu poate gestiona 11 RPS fără probleme. Nu ai nevoie de load balancer complex sau cluster distribuit pentru acest caz de utilizare specific.
# Pseudocod pentru calcul rapid
daily_users = 1_000_000
notification_rate = 0.10
notifications_per_day = daily_users * notification_rate
avg_rps = notifications_per_day / (24 * 3600)
peak_rps = avg_rps * 10 # Factor de vârf
print(f"Peak RPS necesar: {peak_rps:.2f}")
Greșeli frecvente
- Ignorarea factorului de vârf: Calcularea capacității bazate doar pe media zilnică duce la colapsul sistemului în orele de vârf.
- Confundarea lateneței cu throughput-ul: Creșterea throughput-ului nu îmbunătățește automat latența individuală a utilizatorului.
- Subestimarea overhead-ului: Uită de spațiul ocupat de metadatele bazei de date, log-uri sau replicare, care pot dubla necesarul de stocare.
- Presupuneri nerealiste: Folosirea unor valori de referință pentru latența discului sau a rețelei care nu corespund cu infrastructura reală (ex: SSD vs HDD).
Întrebări de interviu
Întrebare: Cât spațiu de stocare ai nevoie pentru a ține istoricul mesajelor unui serviciu de chat similar WhatsApp, pentru 100M utilizatori? Răspuns: Estimăm 50MB/user/an (text + media mică). 100M * 50MB = 5TB/an. Cu replicare 3x și retenție de 2 ani, avem nevoie de ~30TB spațiu fizic util.
Întrebare: Cum estimezi numărul de servere necesare pentru un API cu latență de 50ms și cerere de 10k RPS? Răspuns: Fiecare server poate servi ~20 RPS (1s/0.05s). Pentru 10k RPS, ai nevoie de 10.000 / 20 = 500 servere active, plus altele pentru redundanță și scaling.
Exercițiu
Alocă 45 de minute pentru a estima dimensiunea bazei de date pentru un sistem de rezervări de hoteli cu 10.000 de hoteluri, fiecare având 100 de camere. Presupune că se fac 100.000 de rezervări/lună, fiecare ocupând 1KB de date. Calculează spațiul necesar pentru 5 ani de retenție, adăugând un buffer de 20% pentru metadate și indexi. Scrie pașii de calcul pe hârtie.