Capstone: proiectează o arhitectură completă pentru o companie fictivă la trei scări

Optzeci de lecții. Zece module. Aproximativ 150.000 de cuvinte. Cititorul care a urmărit de la lecția 1 are, până acum, un vocabular funcțional și un cadru de decizie pentru arhitectura de sistem. Aceea era ștacheta pe care a țintit-o cursul, iar restul acestei lecții e exercițiul care face cadrul concret.

Exercițiul e o singură companie fictivă, proiectată de trei ori la trei scări. Compania e o platformă SaaS B2B care ingerează evenimente din aplicațiile clienților, rulează analitice pe acele evenimente și expune atât dashboard-uri, cât și un API. Alege orice formă te lasă să umpli golurile: o unealtă de product analytics, un vendor de observability, o platformă de customer data, un serviciu de feature flagging. Business-ul exact nu contează. Ce contează e că workload-ul e recognoscibil: ingerare, stocare, interogare, servire.

Cele trei scări sunt 100 de utilizatori în săptămâna unu, 100.000 de utilizatori la series A și 100 de milioane de utilizatori în faza de SaaS matur. La fiecare scară, arhitectura e proiectată complet: componente, infrastructură, formă a echipei, cost lunar. Partea interesantă nu e niciun design singular. Partea interesantă e ce se schimbă între scări și de ce. Fiecare schimbare e o decizie arhitecturală pe care a acoperit-o cursul. Capstone-ul e șansa de a le vedea suprapuse.

Scara 1: 100 de utilizatori, săptămâna unu a startup-ului

flowchart LR
    User[Customer browser] --> CDN[CDN]
    CDN --> Static[Static frontend]
    User --> API[Single VM<br/>API + worker]
    API --> DB[(Postgres on the same VM)]
    API --> Stripe[Stripe<br/>billing]
    API --> Sendgrid[Sendgrid<br/>email]

Componente:

• O mașină virtuală care rulează serverul API și un proces worker de fundal una lângă alta. Poate fi o instanță EC2 cu 4 core-uri, un box Hetzner sau un droplet DigitalOcean. Cost: 50 până la 100 EUR pe lună.
• Postgres, rulând pe aceeași VM, cu backup-uri zilnice către object storage.
• Un frontend static (Next.js sau Astro static export, forma preferată din lecția 6) pe un CDN.
• Stripe pentru billing. Sendgrid sau Postmark pentru email tranzacțional.
• Sentry pentru error tracking, free tier. Un cont gratuit de Grafana Cloud cu metrice Prometheus de bază, sau chiar deloc nimic încă.

Cost lunar total: 50 până la 100 EUR pentru infrastructură, plus orice taxează Stripe și Sendgrid în funcție de volum. Echipa: doi sau trei fondatori, fără operațiuni dedicate.

Ce nu e acolo, deliberat. Fără Kubernetes. Fără microservices. Fără Kafka. Fără data warehouse. Fără read replicas. Fără cache. Fără pipeline CI/CD dincolo de un script de deploy în Github Actions. Fără stivă de observability dincolo de Sentry și de metricele proprii ale VM-ului. Fără rotație de on-call, pentru că sunt trei oameni și sunt toți de gardă în mod implicit.

Argumentul arhitectural pentru această formă e argumentul din lecția 6 și lecția 7. Un singur Postgres pe o singură VM servește business-uri reale până la trafic surprinzător de mare (arhitectura GitLab pre-2018, arhitectura Stack Overflow așa cum a fost documentată în faimosul lor post din 2016). Taxa de premature-optimisation pentru a pune Kubernetes și Kafka în fața primilor o sută de utilizatori e enormă, iar opționalitatea pe care o păstrează e iluzorie pentru că business-ul va pivota înainte ca oricare dintre acestea să conteze. Forma e ce a numit lecția 8 started-simpler. Ea e și ce supraviețuiește contactului cu realitatea în această etapă, pentru că realitatea în această etapă e că fondatorii trebuie să livreze funcționalități, nu să opereze infrastructură.

Scara 2: 100.000 de utilizatori, series A

flowchart LR
    User[Customer browser] --> CDN[CDN]
    CDN --> Static[Static frontend]
    User --> LB[Load balancer<br/>multi-AZ]
    LB --> API1[API pod]
    LB --> API2[API pod]
    API1 --> Cache[(Redis<br/>cache + sessions)]
    API2 --> Cache
    API1 --> Primary[(Postgres<br/>primary)]
    API2 --> Primary
    API1 --> Replica[(Postgres<br/>read replica)]
    API2 --> Replica
    Primary -.replication.-> Replica
    API1 --> Kafka[Kafka<br/>event spine]
    Kafka --> Worker[Worker pool]
    Worker --> Primary
    Worker --> S3[(Object storage<br/>files + backups)]
    Worker --> WH[(Warehouse<br/>BigQuery / Snowflake)]
    API1 --> Obs[Observability stack<br/>Datadog / Grafana Cloud]

Componente:

• Postgres, acum un serviciu gestionat (RDS sau Aurora), cu una sau două read replicas. Aplicația a fost refactorizată să rutați citirile către replicile unde consistența eventuală e acceptabilă (lecția 25 și lecția 26).
• Un pool separat de worker pentru job-urile de fundal, rulând pe același cluster Kubernetes ca pod-urile API sau pe o ofertă serverless precum ECS Fargate.
• Redis pentru cache și stocare de sesiuni (lecția 18). Citirile fierbinți care loveau înainte Postgres lovesc acum Redis. Invalidarea cache-ului e prima problemă grea a echipei.
• Kafka ca event spine (lecția 42). Evenimentele clienților curg în Kafka și sunt consumate de pool-ul de worker, de loader-ul de warehouse și de orice alt sistem din aval. Forma event-driven din lecția 47 începe să dea roade.
• Object storage pentru fișierele uploadate de utilizatori și backup-urile bazei de date. CDN în fața frontend-ului static și a oricărei media cu utilizator.
• Deployment multi-AZ într-o singură regiune (lecția 76). Primarul Postgres, replica și nodurile Kubernetes sunt distribuite în trei availability zones. O cădere a unei singure AZ nu doboară platforma.
• Un warehouse (BigQuery, Snowflake sau Redshift) cu date încărcate din baza de date operațională via CDC (lecția 46) sau ELT programat (lecția 33) plus evenimente din Kafka.
• Un pipeline CI/CD pentru codul aplicației (lecția 51 și 52) și Terraform sau Pulumi pentru infrastructură (lecția 53).
• O stivă de observability de bază: Datadog sau Grafana Cloud, metrice Prometheus, logging structurat, distributed tracing pe căile critice de cerere (lecția 59). SLO-uri definite pentru primele trei flow-uri cu utilizator (lecția 60).

Cost lunar total: 10.000 până la 30.000 EUR, în funcție de forma traficului și cât din el a fost over-engineered. Echipa: 10 până la 30 de ingineri, un inginer dedicat de operațiuni sau SRE care probabil are și responsabilități de produs.

Schimbările arhitecturale față de scara 1 sunt exact cele acoperite de curs. Read replicas pentru că traficul de citire le justifică acum. Cache Redis pentru că bugetul de latență pentru cele mai comune interogări nu permite încă un round-trip la baza de date. Kafka pentru că numărul de integrări a traversat pragul unde conexiunile point-to-point devin un ghem. Multi-AZ pentru că SLA-ul pe care îl menționează acum contractele o cere. Un warehouse pentru că interogările de analitice încep să interfereze cu baza de date operațională. Un pipeline CI/CD pentru că echipa e suficient de mare încât deploy-urile manuale sunt acum o sursă de outage.

Ce încă nu e acolo. Fără multi-region. Fără sharding. Fără microservices, dincolo de câteva servicii mici care și-au câștigat independența având nevoie cu adevărat de caracteristici diferite de scalare. Fără echipă dedicată de platformă, echipă dedicată de SRE sau echipă dedicată de securitate. Fără SOC 2, deși compania începe procesul. Fără flotă GPU. Arhitectura are mai multe părți decât scara 1, dar fiecare parte și-a câștigat locul rezolvând o problemă pe care echipa o avea cu adevărat.

Scara 3: 100 de milioane de utilizatori, SaaS matur

flowchart TB
    subgraph Edge[Edge layer]
        CDN[Global CDN]
        WAF[WAF + DDoS protection]
    end
    subgraph US[US region]
        US_LB[Regional load balancer]
        US_API[API services<br/>Kubernetes cluster]
        US_DB[(Sharded Postgres / Vitess)]
        US_Cache[(Redis cluster)]
        US_Kafka[Kafka cluster]
    end
    subgraph EU[EU region]
        EU_LB[Regional load balancer]
        EU_API[API services<br/>Kubernetes cluster]
        EU_DB[(Sharded Postgres / Vitess)]
        EU_Cache[(Redis cluster)]
        EU_Kafka[Kafka cluster]
    end
    subgraph Data[Data platform]
        Lake[(Lakehouse<br/>Iceberg / Delta)]
        WH[(Warehouse)]
        ML[ML platform]
    end
    Edge --> US_LB
    Edge --> EU_LB
    US_Kafka -.MirrorMaker.-> EU_Kafka
    US_Kafka --> Lake
    EU_Kafka --> Lake
    Lake --> WH
    Lake --> ML

Componente:

• Postgres sharded (via Vitess sau Citus) sau o migrare la o bază de date distribuită (Spanner, CockroachDB, Aurora). Decizia între sharding-ul Postgres-ului existent și migrarea la o bază de date distribuită a fost proiectul de mai multe trimestre descris de lecția 29, iar oricare rezultat e defendabil.
• Multi-region. Active-active pentru tier-ul cu citiri grele, active-passive pentru tier-urile care nu pot tolera complexitatea rezolvării conflictelor (lecția 75). Clienții sunt rutați către regiunea cea mai apropiată de ei prin GeoDNS, iar datele sunt replicate între regiuni cu orice model de consistență a decis echipa să trăiască.
• Granițe de microservices care se potrivesc cu granițele echipelor (lecția 73). Arhitectura nu e „microservices” pentru că microservices-ul era scopul; e microservices pentru că echipa are acum sute de ingineri, iar costul social al unui singur deployable împărțit de o sută de ingineri e mai mare decât costul operațional al unei sute de deployables coordonate printr-un service mesh.
• O platformă de date completă: lakehouse (lecția 37) pe object storage cu Iceberg sau Delta, un warehouse pentru workload-urile BI, un feature store, un model registry, un experiment tracker și infrastructura de serving din lecția 79. Pipeline-urile de streaming (lecțiile 41 până la 48) alimentează totul aproape în timp real.
• O stivă completă de observability cu dashboard-uri custom per echipă, distributed tracing prin fiecare serviciu, SLO-uri și error budgets per user journey critic, retenție de log-uri scalată pentru a respecta cerințele de reglementare pe care le are acum compania.
• Echipe dedicate de platformă: o echipă de developer experience care deține CI/CD și uneltele de developer, o echipă de platformă de date care deține warehouse-ul și lakehouse-ul, o echipă SRE care deține răspunsul la incidente și programul de on-call, o echipă de infrastructură care deține Kubernetes și conturile de cloud subiacente, o echipă de securitate care deține certificările de compliance și managementul vulnerabilităților.
• Certificări de compliance: SOC 2 Type II, ISO 27001, PCI DSS dacă compania atinge direct date de carduri, programe GDPR și CCPA cu infrastructura de data residency, ștergere și consimțământ pe care acestea le cer (lecția 78). Programul de compliance e el însuși o linie de buget de mai multe milioane de euro.
• Un program formal de optimizare a costurilor (Modulul 9), cu o funcție FinOps, revizuire lunară a unit economics, management de reserved-instance și savings-plan, storage tiering și porți explicite pe orice schimbare arhitecturală care afectează material factura.

Cost lunar total: o fracțiune din venit. Magazinele bine conduse țin costul de infrastructură sub cinci procente din venit la această scară; magazinele mai puțin bine conduse sunt la cincisprezece procente, iar CFO-ul pune întrebări țintite. Echipa: sute de ingineri, cu echipele dedicate de platformă de mai sus reprezentând zece până la douăzeci la sută din headcount.

Schimbările arhitecturale față de scara 2 sunt din nou cele acoperite de curs. Sharding pentru că pattern-ul Postgres cu un singur primar a atins plafonul (lecția 29). Multi-region pentru că cei mai mari clienți nu vor semna fără el (lecția 75). Microservices pentru că granița de echipă (lecția 73) o cere. Certificări de compliance pentru că mișcarea de vânzări enterprise le cere (lecția 78). Programul de optimizare a costurilor pentru că la această scară, jumătate de procent din venit înseamnă bani reali.

Ce sper să fie încă recognoscibil din scara 1: Postgres e încă baza de date, chiar dacă e sharded, sau wrappat în Vitess, sau înlocuit cu un sistem distribuit compatibil Postgres. Kafka e încă spine-ul. Frontend-ul static e încă servit de pe un CDN. Forma sistemului e aceeași; constantele sunt diferite. Acela e firul pe care a încercat cursul să-l tragă de la lecția 1.

Ce știi acum

Un paragraf per modul, în engleză simplă, despre ce poate raționa cititorul acum.

Modulul 1, lecțiile 1 până la 8: fundații. Ce e arhitectura, cerințele funcționale versus non-funcționale, modelul C4, architectural decision records, limbajul trade-off-urilor, prima arhitectură și când încetează să mai funcționeze. Te poți uita la un sistem și poți spune care îi sunt atributele de calitate, unde s-au făcut trade-off-urile și ce fel de sistem e. Poți scrie un ADR.

Modulul 2, lecțiile 9 până la 16: teoria sistemelor distribuite. Cele opt fallacies, CAP, PACELC, modele de consistență, timp și ceasuri, consensus, two-phase commit, semantici de delivery. Poți citi documentația unei baze de date și înțelege ce promite și ce nu. Poți să te cerți cu un vendor despre caracterizarea lor CAP fără să blufezi.

Modulul 3, lecțiile 17 până la 24: primitive de stocare. Relațional, key-value, document, wide-column, time-series, graph, vector, polyglot persistence. Știi la ce e bună fiecare formă, la ce e proastă și de ce un sistem real folosește de obicei trei dintre ele.

Modulul 4, lecțiile 25 până la 32: replicare și partiționare. Pattern-uri de replicare, replication lag, partiționare, hot keys, strategii de sharding, split-brain, interogări cross-shard și studiul de caz Discord. Poți raționa despre o foaie de parcurs de scalare pentru o bază de date.

Modulul 5, lecțiile 33 până la 40: batch. ETL versus ELT, fundamentele batch, Spark, arhitectura medallion, lakehouse, batch idempotent, backfill-uri și studiul de caz Netflix. Poți proiecta un pipeline batch care nu corupe warehouse-ul la a treia retry.

Modulul 6, lecțiile 41 până la 48: streaming. De ce streaming, Kafka, stream processors, event-time și watermarks, exactly-once, CDC și outbox, lambda versus kappa și studiul de caz Uber. Poți citi o diagramă de arhitectură de streaming și înțelege trade-off-urile din fiecare cutie.

Modulul 7, lecțiile 49 până la 56: deployment. Git branching, trunk-based development, CI și CD pentru date, IaC, Docker, Kubernetes și studiul de caz Stripe. Poți lua o echipă care face deploy manual vinerea și o poți ghida pe drumul către deployment de douăzeci de ori pe zi.

Modulul 8, lecțiile 57 până la 64: operațiuni. Orchestrare, orchestrare orientată pe asset-uri, observability, SLO-uri și error budgets, calitatea datelor, răspuns la incidente, on-call și studiul de caz Airbnb. Poți lua o platformă existentă și să o transformi din „o grămadă de pipeline-uri” în „ceva ce o echipă poate rula”.

Modulul 9, lecțiile 65 până la 72: cost. Aisbergul costurilor, costuri de stocare, costuri de rețea, right-sizing pentru compute, costul interogărilor, costuri GPU, problema data egress și calculul rebuild-versus-buy. Poți citi o factură de cloud și ști ce să întrebi.

Modulul 10, lecțiile 73 până la 80: preocupări de scaling-out. Granițe de microservices, legea lui Conway, pattern-uri multi-region, high availability dincolo de multi-AZ, considerații de reglementare și compliance, platforma ML și acest capstone. Poți să te alături unei conversații senior de arhitectură și să o urmărești.

Acela e vocabularul funcțional. Dacă e suficient depinde de ce face cititorul cu el în continuare.

Unde să mergi mai departe

Cinci recomandări concrete pentru ce să citești după acest curs.

Designing Data-Intensive Applications, de Martin Kleppmann. Citește-o cap-coadă. Cursul a fost un tur; cartea e adâncimea. Fiecare subiect din Modulele 2 până la 6 are un capitol care merge mai în profunzime și multe referințe din curs trimit înapoi la ea. Ediția din 2017 e încă textul canonic în 2026.

The SRE Book și The SRE Workbook, ambele gratuite la https://sre.google/books/. Practicile publicate de echipa SRE de la Google despre operarea sistemelor mari. Cursul a acoperit conceptele SRE (SLO-uri, error budgets, on-call, răspuns la incidente) la nivel de arhitectură; aceste cărți sunt adâncimea de practician. Workbook-ul în special e plin de șabloane și exemple lucrate care se traduc direct în runbooks.

Bloguri de inginerie. Abonează-te la echipele de inginerie care publică, ale căror studii de caz au alimentat cursul: Netflix Tech Blog, Uber Engineering, Stripe Engineering, Discord Engineering, Pinterest Engineering, Airbnb Engineering, Cloudflare Blog, Figma Engineering. Raportul semnal-zgomot e mare; un an de citit va împrospăta și extinde majoritatea conținutului din acest curs.

Celelalte cursuri de pe acest site. Cursul ăsta e lentila de arhitectură; cursul de SQL Server acoperă în adâncime stratul de bază de date, cursul de PySpark acoperă motorul modern de batch și streaming, iar cursul de Python acoperă straturile de aplicație și ML. Împreună sunt trusa completă de unelte de data engineering.

Un workload real. Cea mai puternică buclă de învățare e cea în care cititorul ia un sistem real de la job-ul lui, aplică cadrul din acest curs, găsește trade-off-urile care au fost făcute implicit și fie le documentează ca ADR-uri, fie propune schimbări care ar justifica un trade-off diferit. Conținutul cursului trece din vocabular pasiv în practică activă în momentul în care e folosit.

Încheiere

Ai acum vocabularul. Poți citi un anunț de job, un pitch de vendor, un post de blog de inginerie, o diagramă de arhitectură sau o schiță pe whiteboard a unui inginer senior, și poți urmări. Poți pune întrebarea care expune presupunerea. Poți numi trade-off-ul care a fost făcut implicit. Poți schița propria arhitectură și argumenta pentru alegerile pe care le-ai făcut. Asta a fost rostul a optzeci de lecții de arhitectură de sistem.

Restul e practică. Sistemele care mișcă lumea sunt cele care au supraviețuit contactului cu realitatea, iar realitatea e ce vei lucra începând de mâine. Constantele diferă. Formele nu. Du-te și construiește ceva.

Citări și lectură suplimentară

• Martin Kleppmann, “Designing Data-Intensive Applications”, O’Reilly Media, 2017, https://dataintensive.net/ (consultat 2026-05-01). Referința de adâncime pentru aproape fiecare subiect din acest curs.
• Beyer, Jones, Petoff, Murphy (eds.), “Site Reliability Engineering: How Google Runs Production Systems”, O’Reilly Media, 2016, gratuit la https://sre.google/sre-book/table-of-contents/ (consultat 2026-05-01). Textul SRE fundamental.
• Beyer, Murphy, Rensin, Kawahara, Thorne (eds.), “The Site Reliability Workbook: Practical Ways to Implement SRE”, O’Reilly Media, 2018, gratuit la https://sre.google/workbook/table-of-contents/ (consultat 2026-05-01). Volumul companion de tip hands-on.
• Netflix Tech Blog, https://netflixtechblog.com/ (consultat 2026-05-01).
• Uber Engineering, https://www.uber.com/blog/engineering/ (consultat 2026-05-01).
• Stripe Engineering, https://stripe.com/blog/engineering (consultat 2026-05-01).
• Discord Engineering, https://discord.com/category/engineering (consultat 2026-05-01).
• Pinterest Engineering, https://medium.com/pinterest-engineering (consultat 2026-05-01).
• Airbnb Engineering, https://medium.com/airbnb-engineering (consultat 2026-05-01).
• Cloudflare Blog, https://blog.cloudflare.com/ (consultat 2026-05-01).
• Figma Engineering, https://www.figma.com/blog/engineering/ (consultat 2026-05-01).