Rolul de Software Architect

Subiect din roadmap-ul Software Architect

Vezi în roadmap și marchează progresul Întreabă AI Tutor

Rolul de Software Architect este puntea critică dintre nevoile de business și implementarea tehnică, asigurând că soluțiile nu funcționează doar azi, ci scalabil mâine. În practică, arhitectul nu scrie tot codul, ci definește constrângerile, alege tehnologiile și previne colapsul sistemului pe măsură ce echipa crește. Fără această viziune holistică, proiectele tind să devină „spaghetti code”, imposibil de întreținut sau de extins rapid. Deciziile tale influențează direct viteza de livrare, costurile de infrastructură și stabilitatea produsului final.

Concepte cheie

  • Trade-offs: Orice decizie tehnică are avantaje și dezavantaje; arhitectul trebuie să aleagă cea mai bună opțiune pentru contextul specific, nu cea „perfectă” teoretic.
  • Scalabilitate: Capacitatea sistemului de a gestiona creșterea volumului de date sau a utilizatorilor, fie prin adăugarea de resurse (scale-up) sau noduri (scale-out).
  • Tenzii architecturale: Caracteristici non-funcționale critice precum latența, disponibilitatea, consistența datelor și securitatea, care trebuie echilibrate constant.
  • Design Patterns: Soluții reutilizabile pentru probleme recurente de design (ex: Singleton, Factory, Observer) care simplifică comunicarea și menținerea codului.
  • Microservicii vs Monolit: Alegerea dintre o aplicație unitară și una împărțită în servicii independente, bazată pe complexitatea domeniului și capacitatea echipei.
  • API Design: Definirea clară a contractelor de comunicare între componente, asigurând interoperabilitatea și independența echipelor de dezvoltare.
  • Observability: Capacitatea de a înțelege starea internă a sistemului bazată pe datele externe (logs, metrics, traces), esențială pentru debugging în producție.

Exemplu practic

Imagină-ți un sistem de e-commerce care suferă la momentul lansării unui produs limitat. Un monolit clasic ar bloca toată aplicația dacă baza de date este suprasolicitată.

# Conceptual: Separarea responsabilităților
class OrderService:
    def __init__(self, db, queue):
        self.db = db
        self.queue = queue # Message Broker (ex: RabbitMQ/Kafka)

    def create_order(self, user_id, items):
        # 1. Salvăm comanda asincron sau în coadă
        self.queue.publish("order_created", {"user_id": user_id})
        return {"status": "pending"}

Prin trimiterea evenimentului în coadă, interfața utilizatorului răspunde instantaneu, iar procesarea efectivă (scadere stoc, facturare) se face în background. Acest pattern decuplează componentele și îmbunătățește experiența utilizatorului.

Greșeli frecvente

  • Over-engineering: Introducerea de microservicii sau baze de date complexe pentru o aplicație simplă, doar pentru că sunt „la modă”.
  • Ignorarea costurilor operaționale: Alegerea unei tehnologii open-source care necesită o echipă dedicată de DevOps pentru a fi mentenută eficient.
  • Lipsa documentației vizuale: Arhitectura nu poate fi înțeleasă corect de nou-veniți fără diagrame clare (C4 model, UML) actualizate.
  • Decizii centralizate excesive: Blocarea echipei de dezvoltare prin aprobări lungi pentru fiecare mică decizie tehnică, încetinind livrarea.

Întrebări de interviu

1. Cum alegi între o bază de date SQL și NoSQL? Răspuns: Bazez decizia pe structura datelor și tipul de interogări. SQL pentru date relaționale, tranzacții ACID stricte și integritate referențială. NoSQL pentru date nestructurate, scalabilitate orizontală masivă sau modele de acces rapide și simple.

2. Ce faci când o decizie tehnică este respinsă de stakeholderi din business? Răspuns: Ascult argumentele lor (de obicei legate de cost sau timp). Explic impactul tehnic pe termen lung al refuzului și cautăm un compromis care să acopere nevoia imediată fără a compromite viabilitatea sistemului.

3. Cum gestionezi tehneologia legacy într-un sistem modern? Răspuns: Aplic strategia Strangler Fig, refactorizând treptat funcționalitățile vechi în servicii noi, până când sistemul legacy poate fi oprit complet, minimizând riscul de întrerupere a serviciilor.

Exercițiu

Alocă 45 de minute pentru a proiecta arhitectura unui sistem simplu de rezervare a locurilor la cinema. Desenează pe hârtie sau folosește un tool online:

  1. Identifică cele 3 entități principale (ex: User, Movie, Seat).
  2. Alege o tehnologie pentru stocarea datelor și justifică alegerea (SQL vs NoSQL).
  3. Desenează fluxul pentru „Rezervă un bilet”: cum interacționează frontend-ul, backend-ul și baza de date?
  4. Notează un singur punct de eșec potențial și cum l-ai preveni (ex: double booking).

Subteme