Dissenyar una arquitectura que escali de 1.000 a 100.000 usuaris
«Premature optimization is the root of all evil.» La frase de Knuth, la cita tothom. Però hi ha una variant que ningú no esmenta: la ignorància prematura sobre escalabilitat és igual de perillosa.
L'objectiu no és construir per a 100.000 usuaris des del primer dia. Això és sobreenginyeria. L'objectiu és evitar prendre, a 1.000 usuaris, decisions que facin impossible arribar a 100.000 sense reescriure-ho tot de zero.
He vist startups passar-se tres mesos dissenyant una arquitectura de microserveis per a un producte que encara no té el primer client. I n'he vist d'altres que arriben a 10.000 usuaris i han de congelar el desenvolupament de funcionalitats durant dos mesos perquè la base de dades s'està morint i l'arquitectura no els permet escalar horitzontalment.
Tots dos extrems són evitables. Aquí tens un full de ruta realista del que necessites a cada fase.
Fase 1: de 0 a 1.000 usuaris — el monòlit ben fet
En aquesta fase, la teva prioritat és el producte, no la infraestructura. Has de validar que el que construeixes té sentit, iterar ràpid i no malgastar energia en problemes que encara no tens.
L'arquitectura correcta aquí és simple:
- Un monòlit. Rails, Django, Express, Laravel, Next.js. El que el teu equip conegui millor. Un sol repositori, un sol desplegament.
- PostgreSQL. Probablement la decisió de base de dades més segura que pots prendre. Suporta JSON, cerca de text complet i transaccions ACID, i amb bons índexs escala còmodament fins a milions de files.
- Un servidor. Un VPS a Hetzner, una instància d'AWS, un dyno de Heroku. Una sola màquina amb la teva aplicació i la teva base de dades.
- Desplegaments simples. Git push, CI/CD bàsic amb GitHub Actions o GitLab CI. Sense contenidors si no els necessites.
El que SÍ que has de fer bé des del principi:
- Aplicació stateless. El servidor d'aplicació no ha de guardar estat ni en memòria ni en disc. Les sessions van a la base de dades o a Redis; els fitxers, a S3. Això és crític: quan necessitis afegir un segon servidor, no pots tenir estat local.
- Índexs a la base de dades. Cada consulta que filtra o ordena necessita un índex. Això no és optimització prematura: és higiene bàsica. Una consulta sense índex que triga 50 ms amb 100 registres en triga 5 segons amb 100.000.
- Separar la lògica de negoci de la capa de presentació. Encara que tinguis un monòlit, estructura el codi de manera que, el dia que necessitis una API per a una app mòbil, no hagis de reescriure la lògica de negoci.
Fase 2: de 1.000 a 10.000 usuaris — les primeres optimitzacions
Aquí és on comencen a aparèixer els primers colls d'ampolla. Les pàgines triguen més a carregar, la base de dades pateix amb certes consultes i els processos llargs bloquegen peticions.
El que has d'afegir:
- Memòria cau amb Redis. No ho posis tot a la cau de cop. Identifica els endpoints més lents o més sol·licitats i guarda'n les respostes. Una pàgina de producte que fa 5 consultes a la base de dades i se serveix 10.000 vegades al dia és una candidata perfecta.
- CDN per als recursos estàtics. Imatges, CSS, JavaScript. Cloudflare, CloudFront, Bunny CDN. Redueixes la càrrega del servidor i millores els temps de càrrega per a usuaris d'altres regions.
- Rèpliques de lectura a la base de dades. Si la teva aplicació fa moltes més lectures que escriptures (la majoria ho fan), configura una rèplica de lectura de PostgreSQL. Les escriptures van al primari; les lectures, a la rèplica. Dupliques la capacitat de lectura sense tocar ni una línia de codi d'aplicació.
- Feines en segon pla. Tot el que no necessita resposta immediata surt del cicle petició/resposta. Enviar correus, processar imatges, generar informes, sincronitzar amb tercers. Celery per a Python, Sidekiq per a Ruby, BullMQ per a Node.js.
L'error més comú en aquesta fase: no monitorar. Si no mesures, no pots optimitzar. Munta alguna cosa que et doni visibilitat sobre temps de resposta, consultes lentes i ús de recursos. No cal res car: les mètriques bàsiques del teu proveïdor de hosting més una eina com Grafana amb Prometheus ja són suficients.
Fase 3: de 10.000 a 100.000 usuaris — escalar horitzontalment
Aquí és on l'arquitectura demostra si aquelles decisions inicials eren bones. Si la teva aplicació és stateless i la base de dades té bons índexs, aquesta transició és assumible. Si no, prepara't per a setmanes de refactorització.
El que necessites:
- Balancejador de càrrega + diversos servidors d'aplicació. Nginx, HAProxy o el balancejador del teu proveïdor de núvol. Si l'aplicació és stateless (com hauria de ser-ho des de la Fase 1), això és aixecar servidors i apuntar-hi el balancejador.
- Optimització seriosa de la base de dades. Connection pooling amb PgBouncer. Anàlisi de consultes lentes amb EXPLAIN ANALYZE. Índexs compostos per a les consultes més freqüents. Valora vistes materialitzades per als informes pesants.
- Separar els serveis que consumeixen molts recursos. Si tens un procés que devora recursos (processament d'imatges, generació de PDF, càlculs complexos), mou-lo a un servei a part. No és un microservei en el sentit arquitectònic: és simplement treure feina pesant del procés principal.
- Cues de missatges per al processament asíncron. RabbitMQ o Amazon SQS. Per a la comunicació entre serveis i per absorbir pics de trànsit. Una punta de trànsit no t'hauria de tombar el sistema si els processos no crítics són en una cua.
- Autoescalat. Configura regles perquè els servidors d'aplicació escalin sols segons la CPU o el nombre de peticions. A AWS, això és un Auto Scaling Group. A Kubernetes, un Horizontal Pod Autoscaler (però probablement encara no necessites Kubernetes).
Les decisions que importen des del primer dia
Si ho hagués de reduir a una sola llista del que cal fer bé des del principi, seria aquesta:
- Disseny stateless. Cap estat al servidor d'aplicació. Sessions a Redis o a la base de dades; fitxers en emmagatzematge extern.
- Sessions fora del procés. No guardis mai les sessions a la memòria del procés. Quan escalis a diversos servidors, un usuari pot caure en un servidor diferent a cada petició.
- Estratègia d'índexs. Cada consulta amb WHERE o ORDER BY necessita un índex. Revisa-ho periòdicament amb el planificador de consultes.
- Separar els patrons de lectura i d'escriptura. Encara que no tinguis rèpliques de lectura, estructura el codi de manera que sigui fàcil apuntar les lectures a una altra connexió quan arribi el moment.
- Migracions reversibles. Cada canvi a l'esquema de la base de dades ha de poder-se desfer. No té a veure directament amb l'escalabilitat, però t'estalvia caigudes quan alguna cosa surt malament a producció.
El que NO has de fer
Això és tan important com tot l'anterior:
- No facis sharding de la base de dades a 5.000 usuaris. El sharding és complex, introdueix un sobrecost operacional enorme i probablement no el necessitaràs fins als centenars de milers o milions d'usuaris. Un PostgreSQL ben configurat aguanta molt més del que et penses.
- No introdueixis Kubernetes a 10.000 usuaris. K8s resol problemes d'orquestració a escala. Si tens 3-5 servidors, Docker Compose o un balancejador simple amb instàncies és més que suficient. La complexitat operacional de Kubernetes no es justifica fins que tens desenes de serveis.
- No construeixis microserveis abans de tenir 3 equips. Els microserveis són una estratègia organitzativa, no tècnica. Si un sol equip ho manté tot, els microserveis només hi afegeixen latència de xarxa, complexitat de desplegament i maldecaps de depuració.
- No optimitzis sense mesurar. Cada optimització ha d'estar avalada per dades. «Crec que la base de dades va lenta» no és suficient. «Aquesta consulta triga 800 ms i s'executa 50.000 vegades al dia» sí que ho és.
La llista de control abans de cada fase de creixement
Abans de passar a la fase següent, comprova:
- Tens monitoratge que et digui on són els colls d'ampolla reals?
- La teva aplicació pot córrer en diverses instàncies sense problemes?
- Les consultes més freqüents tenen els índexs adequats?
- Els processos pesants són fora del cicle petició/resposta?
- Pots desplegar sense temps d'aturada?
- Tens còpies de seguretat automàtiques, i n'has provat la restauració?
Escalar és més fàcil la segona vegada
La diferència entre escalar patint i escalar amb confiança és haver passat pel procés abans. Un arquitecte que ja ha portat un sistema de 1.000 a 100.000 usuaris sap quins patrons importen a cada fase i, més important encara, quins encara no toquen.
A Conectia, els enginyers sèniors que connectem amb startups europees han viscut aquestes fases en productes reals. No et proposaran Kubernetes per al teu MVP ni microserveis per al teu equip de quatre persones. T'ajudaran a prendre les decisions correctes per a la fase on ets ara, deixant la porta oberta a la següent.
Perquè escalar no és un fet puntual. És una sèrie de decisions incrementals. I cadascuna és molt més fàcil quan algú del teu equip ja sap què ve després.
El teu producte creix i no tens clar que la teva arquitectura aguanti el següent ordre de magnitud? Parla amb un CTO — et posem en contacte amb arquitectes que ja han escalat sistemes com el teu.
