Aseară, în timpul Super Bowl, ai.com a avut „momentul lor de glorie”: un spot TV național care a trimis zeci de milioane de oameni către site în câteva zeci de secunde. Vorbim de o campanie estimată la milioane de dolari doar pentru reclamă, peste un domeniu evaluat la aproximativ 70 de milioane de dolari și un spot de 1 minut evaluat în jur de 15 milioane de dolari, conform presei tech. Alte surse vorbesc de un buget de circa 8 milioane de dolari pentru expunerea de Super Bowl, dar toate sunt de acord asupra unui lucru: s-au cheltuit foarte mulți bani pe atenție.
Rezultatul?
Traficul a venit, oamenii au încercat să intre pe ai.com... și site-ul a început să cadă. Utilizatorii raportau că platforma este de neaccesat sau blocată în bucle de sign‑up eșuate.
CEO‑ul, Kris Marszalek (cunoscut și ca CEO Crypto.com), a ieșit rapid pe X și a spus celebra frază: „we prepared for scale, but not for THIS”, punând o parte din vină pe limitele de rată ale Google pentru autentificare.
Pe scurt:
Au cheltuit milioane pe domeniu, brand și reclamă, dar infrastructura care trebuia să susțină tot acest hype a cedat exact când lumea a dat click.
Unde a crăpat, de fapt, stack-ul lor
Din ce a comunicat chiar CEO‑ul, punctul principal de eșec a fost login‑ul:
Onboarding-ul era centrat pe „Continue with Google” – un singur flux de autentificare, un singur punct critic.
Când au intrat milioane de utilizatori în câteva secunde, Google a început să limiteze traficul (rate limiting), blocând practic înrolarea de noi conturi.
Două probleme masive aici:
1. Single Point of Failure (SPOF)
Tot onboarding‑ul era dependent de un singur provider de auth. Dacă acel provider te limitează sau cade, te-ai oprit. Nicio alternativă, niciun fallback.
2. Scalare gândită „din prezent”, nu „din viitor”
Au „pregătit” infrastructura pentru un volum mare, dar aparent pentru creștere treptată, nu pentru un tsunami instant generat de un spot de Super Bowl.
Din exterior, pare că:
- Nu au testat realist scenarii de „Super Bowl traffic spike” (zeci/sute de mii de request‑uri pe secundă).
- Nu au avut margine de siguranță suficientă (capacity buffer).
- Nu au avut un plan B clar pentru când auth-ul prin Google se lovește de rate limiting.
De ce povestea ai.com este o lecție pentru orice fondator și marketer
Orice fondator visează să „spargă” internetul cu o lansare: să cumpere un domeniu puternic, să bage milioane în ads, să creeze hype. Dar povestea ai.com arată clar ceva foarte simplu:
Atenția este scumpă. Infrastructura instabilă îți mănâncă fiecare euro cheltuit pe marketing.
Dacă ești fondator, CTO sau marketer care împinge bugete serioase în campanii, ordinea corectă este:
- Întâi te asiguri că poți susține succesul.
- Abia apoi plătești ca să-ți vină succesul la ușă.
În caz contrar, plătești de două ori:
- O dată bani – pentru trafic.
- O dată în reputație – pentru că primii tăi utilizatori văd un „site down” sau „try again later”.
Lecții tehnice și de business din fail-ul ai.com
1. Nu lansa o campanie masivă fără load testing serios
Înainte să cumperi un spot TV, un banner pe homepage la un mare publisher sau să dai drumul unei campanii cu influenceri de milioane de reach, trebuie să știi exact:
- Câte request‑uri pe secundă poate duce aplicația ta fără să înceapă să moară (95th/99th percentile latencies, error rate).
- Ce se întâmplă când treci peste aceste limite: se degradează grațios sau explodează tot?
Tool-uri practice pentru load & stress testing:
- k6 (scriptable, dev‑friendly)
- Locust (Python-based, foarte flexibil)
- JMeter (clasic, dar încă util)
Ideea nu este doar „să faci un test”, ci:
- Să simulezi patternuri reale de trafic (burst-uri, spikes, ramp-up agresiv).
- Să vezi unde crapă baza de date, auth-ul, API‑urile externe, queue‑urile etc.
2. Evită Single Points of Failure (mai ales pe login)
ai.com a pus totul pe „Continue with Google”. Convenabil pentru UX, dar sinucidere pentru fiabilitate la scară mare.
Un design mai „matur” pentru auth într-un scenariu de hype ar fi:
- Multiple opțiuni de login: Email + parolă / magic link. Google, Apple, poate Microsoft, dar nu ca singura opțiune.
- Fallback logic: Dacă Google API începe să dea rate limit/errors, ascunzi temporar opțiunea și împingi utilizatorul spre o alternativă (email login).
- Layer de caching și retry: Ex. token‑urile și meta‑datele de sesiune să fie cache‑uite ca să nu lovești providerul extern la fiecare mic gest.
3. Autoscaling REAL, nu doar un checkbox bifat
Mulți cred că „suntem pe cloud, deci autoscalează AWS/GCP/Azure pentru noi”. În practică:
- Autoscaling funcționează bine pentru creșteri graduale.
- Pentru spike de gen Super Bowl, contează:
- să ai deja resursele „warm” (pre‑scaled înainte de campanie),
- să ai limite superioare suficiente (max instances),
- să nu te lovești de limite de cont (API rate limits, quota, concurrency caps).
Checklist minim:
- Configuri HPA / autoscaling policies astfel încât să reacționeze rapid la CPU/RPS/latency.
- Ridici manual capacitatea înainte de campanie (dublu/triplu față de ce a rezultat în load testing).
- Verifici quota & rate limits la toți providerii externi: auth (Google, Apple etc.), payment gateway, vector DB, AI API, mail provider.
4. Nu depinde orbește de limitele altora (Google, OpenAI, etc.)
ai.com a aflat live, în fața lumii, că infrastructura lor depinde de limitările Google OAuth.
La scară mare, aproape nimeni nu trăiește într-un vacuum. Fiecare startup AI depinde de: Cloud (AWS/GCP/Azure), AI API (OpenAI, Anthropic, etc.), Auth (Google, Apple, Facebook), CDN & DNS (Cloudflare, AWS), payment processors...
Pentru fiecare dependență critică întreabă-te:
- Ce se întâmplă dacă îmi răspunde cu eroare sau rate limiting?
- Pot face coadă (queue) locală ca să nu pierd cererile?
- Pot degrada funcționalitatea (de ex. „te înregistrezi și confirmăm mai târziu”, în loc de „nu merge nimic”)?
5. Degradează grațios, nu exploda
Dacă totul merge prost, utilizatorul nu trebuie să vadă un 500 generic. Scenarii de degradare grațioasă:
- Dacă auth extern nu merge: Afișezi un mesaj prietenos: „Avem foarte mult trafic acum. Te putem trece pe o listă de așteptare, lasă emailul și te anunțăm când te putem onboard‑a.” Salvezi email-ul, eventual un hash al datelor, și îi dai follow‑up ulterior.
- Dacă AI‑ul backend e saturat: Oferești un mod „lite” al produsului, cu funcționalitate redusă, dar funcțională.
- Dacă DB-ul e sub presiune: Treci rapid unele pagini pe cache static, amâni anumite task-uri (job-uri asyncrone, queue-uri).
Chiar și în haos, experiența poate fi „ok, sunt copleșiți, dar măcar sunt transparenți și au un plan”, nu „nu funcționează nimic, bye”.
Checklist practic înainte de „lansarea vieții tale”
Dacă mâine ai de dat drumul la un spot TV, o campanie masivă cu influenceri, sau un feature mare promovat în toată presa, poți folosi checklist-ul de mai jos ca șablon:
1. Load & Stress Testing
- Am rulat load test care ajunge la minim 2–3x traficul „optimist” estimat.
- Știu exact unde începe aplicația să încetinească sau să dea erori (grafice, logs).
- Am optimizat bottleneck-urile evidente (query‑uri lente, endpointuri fără cache etc.).
2. Capacitate & Autoscaling
- Am crescut manual capacitatea (CPU/RAM/replicas) peste ce am văzut în teste.
- Am configurat autoscaling cu limite upper suficient de sus.
- Am verificat quota & rate limits la toți providerii externi.
3. Arhitectură fără SPOF critic
- Login-ul nu depinde de un singur provider (ex.: doar Google).
- Am fallback pentru componente cheie (auth, payments, messaging).
- Am dezactivat sau „feature flag-uit” lucrurile non-esențiale care pot consuma resurse inutile la spike.
4. Observability & Alerting
- Am dashboards clare (latency, error rate, RPS, CPU, DB health).
- Am alerte care trag de mine cu 10–15 minute înainte de dezastru, nu după.
- Echipa știe exact cine răspunde la telefon la 3 dimineața.
5. UX de avarie
- Am pagini de „waitlist” / „we’re under heavy load” pregătite, nu le scriu în criză.
- Am mesaje clar traduse și prietenoase, nu erori generice.
- Am un plan de comunicare (social media, email) dacă ceva se rupe.
Concluzie: Nu repeta ai.com
Povestea ai.com este perfectă pentru prezentări de „what NOT to do”:
- Au cumpărat unul dintre cele mai scumpe domenii din industrie.
- Au investit milioane în reclame în cel mai scump spațiu media al anului.
- Au reușit să atragă atenția a milioane de oameni.
- Iar în momentul adevărului, infrastructura a spus „nu mai pot”.
Pentru orice fondator sau marketer, mesajul este clar:
Scalable marketing fără scalable infrastructure nu este growth. E doar un mod foarte scump de a-ți distruge prima impresie.
Dacă te pregătești de o lansare mare pentru aplicația ta, tratează povestea ai.com ca pe un dress rehearsal mental: verifică-ți stack‑ul, fă load test, scoate SPOF‑urile critice, pregătește fallback‑uri și nu te baza niciodată pe ideea „lasă că duce cloud-ul”.
Nu vrei să ajungi omul care spune după o campanie de milioane: „we prepared for scale, but not for THIS”.
