Introducere

System Design este disciplina care transformă o idee simplă într-o aplicație scalabilă, fiabilă și eficientă din punct de vedere al costurilor. În practică, nu contează doar dacă codul funcționează local, ci cum se comportă sub presiunea a milioane de utilizatori simultani. Abilitatea de a proiecta arhitecturi robuste este esențială pentru rolurile de Senior Engineer, Tech Lead sau Architect, deoarece deciziile luate la acest nivel influențează direct experiența utilizatorului și viabilitatea afacerii.

Concepte cheie

• Scalabilitate: Capacitatea sistemului de a gestiona creșterea traficului adăugând resurse (scale-up) sau noduri suplimentare (scale-out).
• Disponibilitate: Măsura timpului în care sistemul este operațional și accesibil utilizatorilor, adesea măsurată în "nines" (ex: 99.9%).
• Consistența datelor: Garantarea că toți utilizatorii văd aceeași informație actualizată, echilibrând între consistență strictă și eventuală (eventual consistency).
• Load Balancing: Distribuirea traficului intrant între mai multe servere pentru a preveni supraîncărcarea oricărui nod individual.
• Cache: Stocarea temporară a datelor accesate frecvent în memorie rapidă (RAM) pentru a reduce latenta și încărcarea bazei de date.
• Decuplare (Decoupling): Separarea componentelor sistemului folosind cozi de mesaje (message queues) pentru a le face independente și reziliente la eșecuri.
• Single Point of Failure (SPOF): Orice componentă a cărei defecțiune duce la oprirea întregului sistem; arhitectura bună elimină SPOF-urile prin redundanță.

Exemplu practic

Imagină-ți un sistem simplu de postare pe social media. Când un utilizator dă "Post", frontend-ul trimite cererea către un Load Balancer, care o distribuie către unul dintre mai multe servere de aplicație. Serverul nu scrie direct în baza de date principală, ci publică mesajul într-o coadă (ex: RabbitMQ/Kafka). Un worker procesează mesajul asincron, îl validează și îl salvează în baza de date. Dacă baza de date este lentă, un strat de Cache (Redis) servește postările populare instantaneu. Acest design permite sistemului să absoarbă vârfuri de trafic fără a bloca utilizatorul final.

# Pseudocod pentru procesarea asincronă
def handle_post_request(user_id, content):
    # 1. Validare rapidă
    if not validate(content):
        return Error("Invalid content")
    
    # 2. Publicare în coadă (non-blocking)
    message_queue.publish({
        "user_id": user_id,
        "content": content,
        "timestamp": now()
    })
    
    # 3. Răspuns imediat către client
    return Success("Post queued for processing")

def worker_process_message(message):
    # 4. Procesare lentă/asincronă
    save_to_database(message)
    notify_followers(message)
    update_feed_cache(message)

Greșeli frecvente

• Supra-proiectarea (Over-engineering): Introducerea de microservicii complexe pentru un sistem care nu are nevoie de ele încă. Începe monolit modular.
• Ignorarea bottleneck-urilor de bază de date: Nu se optimizează interogările sau schema înainte de a adăuga cache sau replici.
• Lipsa monitorizării: Nu se implementează logging, tracing și alerting, făcând imposibilă diagnosticarea problemelor în producție.
• Neglijarea securității: Trimiterea datelor sensibile în URL-uri sau lipsa autentificării între serviciile interne.

Întrebări de interviu

Cum ai proiecta un URL Shortener ca Bitly? Trebuie să gestionezi scrieri rapide și citiri foarte frecvente. Soluția implică o bază de date pentru maparea ID-ului unic la URL-ul lung, un cache agresiv pentru cele mai populare link-uri și un generator de hashuri eficiente (base62) pentru a crea ID-uri scurte.

Diferența dintre consistența puternică și cea eventuală? Consistența puternică garantează că o citire returnează întotdeauna ultima scriere (ex: tranzacții bancare). Consistența eventuală permite o întârziere până când toate nodurile se sincronizează (ex: feed-ul de știri), oferind performanță superioară și disponibilitate.

Cum previi un Single Point of Failure? Prin redundanță. Dacă un server cade, altul preia traficul. Dacă un data center cade, un altul preia sarcina. Folosirea load balancerelor și a bazelor de date replicate este crucială.

Exercițiu

Designează un sistem de rezervare a locurilor la un cinematograf online.

1. Desenează diagrama de blocuri (Frontend, API, DB, Cache).
2. Explică cum vei gestiona două persoane care încearcă să cumpere același bilet în aceeași fracțiune de secundă (concurrent access).
3. Propune o strategie de caching pentru lista de filme disponibile. Timp estimat: 45 minute.