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 repeteix tothom. Pero hi ha una variant que ningu cita: la ignorancia prematura sobre escalabilitat es igual de perillosa.
L'objectiu no es construir per a 100.000 usuaris des del dia u. Aixo es sobreenginyeria. L'objectiu es no prendre decisions a 1.000 usuaris que facin impossible arribar a 100.000 sense reescriure-ho tot des de zero.
He vist startups que gasten tres mesos dissenyant una arquitectura de microserveis per a un producte que encara no te el seu primer client. I he vist startups que arriben a 10.000 usuaris i han de parar el desenvolupament de features durant dos mesos perque la seva base de dades es mor i la seva arquitectura no permet escalar horitzontalment.
Tots dos extrems son evitables. Aqui va un mapa realista del que necessites a cada fase.
Fase 1: De 0 a 1.000 usuaris — El monolit ben fet
En aquesta fase, la teva prioritat es el producte, no la infraestructura. Necessites validar que el que construeixes te sentit, iterar rapid i no gastar energia en problemes que encara no tens.
L'arquitectura correcta aqui es simple:
- Un monolit. Rails, Django, Express, Laravel, Next.js. El que el teu equip conegui millor. Un sol repositori, un sol deploy.
- PostgreSQL. Probablement la decisio de base de dades mes segura que pots prendre. Suporta JSON, full-text search, transaccions ACID, i escala molt be fins a centenars de milers de registres amb bons indexos.
- Un servidor. Un VPS a Hetzner, una instancia a AWS, un dyno a Heroku. Un sol servidor amb la teva aplicacio i la teva base de dades.
- Deploy simple. Git push, CI/CD basic amb GitHub Actions o GitLab CI. Sense contenidors si no els necessites.
El que SI has de fer be des del principi:
- Aplicacio stateless. El teu servidor d'aplicacio no ha de guardar estat en memoria ni en disc. Les sessions van a la base de dades o a Redis, els arxius van a S3. Aixo es critic perque quan necessitis afegir un segon servidor, no pots tenir estat local.
- Indexos a la base de dades. Cada query que filtra o ordena necessita un index. No es optimitzacio prematura, es higiene basica. Un query sense index que tarda 50ms amb 100 registres tarda 5 segons amb 100.000.
- Separar logica de negoci de la capa de presentacio. Encara que sigui un monolit, estructura el teu codi de manera que el dia que necessitis una API per a una app mobil, no hagis de reescriure la teva logica de negoci.
Fase 2: De 1.000 a 10.000 usuaris — Les primeres optimitzacions
Aqui comences a notar els primers colls d'ampolla. Les pagines triguen mes a carregar, la base de dades comenca a suar en certs queries, i els processos llargs bloquegen requests.
El que necessites afegir:
- Caching amb Redis. No cachegis tot de cop. Identifica els endpoints mes lents o mes frequents i cacheja les seves respostes. Una pagina de producte que es genera amb 5 queries a la base de dades i es serveix 10.000 vegades al dia es candidata perfecta per a cache.
- CDN per a assets estatics. Imatges, CSS, JavaScript. Cloudflare, CloudFront, Bunny CDN. Aixo redueix la carrega del teu servidor i millora els temps de carrega per a usuaris en diferents regions.
- Read replicas de base de dades. Si la teva aplicacio es read-heavy (la majoria ho son), configura una replica de lectura de PostgreSQL. Les escriptures van al primari, les lectures van a la replica. Aixo duplica la teva capacitat de lectura sense tocar una linia de codi d'aplicacio.
- Background jobs. Tot el que no necessita resposta immediata surt del cicle request/response. Enviar emails, processar imatges, generar informes, sincronitzar amb tercers. Celery si uses Python, Sidekiq si uses Ruby, BullMQ si uses Node.js.
L'error mes comu en aquesta fase: no monitoritzar. Si no mesurea, no pots optimitzar. Instal·la alguna cosa que et doni visibilitat sobre temps de resposta, queries lentes i us de recursos. No necessites res car: les metriques basiques del teu proveidor de hosting mes una eina com Grafana amb Prometheus son suficients.
Fase 3: De 10.000 a 100.000 usuaris — Escalar horitzontalment
Aqui es on la teva arquitectura demostra si les decisions primerenques van ser bones. Si la teva aplicacio es stateless i la teva base de dades te bons indexos, aquesta transicio es manejable. Si no, prepara't per setmanes de refactoring.
El que necessites:
- Load balancer + multiples servidors d'aplicacio. Nginx, HAProxy, o el balancejador del teu proveidor cloud. Si la teva aplicacio es stateless (com hauria de ser des de la Fase 1), aixo es afegir servidors i apuntar el balancejador cap a ells.
- Optimitzacio seria de base de dades. Connection pooling amb PgBouncer. Revisio de queries lentes amb EXPLAIN ANALYZE. Indexos compostos per a les queries mes frequents. Considerar materialitzar vistes per a reports pesats.
- Separar serveis pesats. Si tens un proces que consumeix molts recursos (processament d'imatges, generacio de PDFs, calculs complexos), mou-lo a un servei separat. No es un microservei en el sentit arquitectonic, es simplement treure una carrega pesada del proces principal.
- Message queues per a processament asincron. RabbitMQ o Amazon SQS. Per a comunicacio entre serveis i per absorbir pics de carrega. Un spike de trafic no hauria de tombar el teu sistema si els processos no critics estan en una cua.
- Autoscaling. Configura regles perque els teus servidors d'aplicacio escalin automaticament basant-se en CPU o nombre de requests. A AWS, aixo es un Auto Scaling Group. A Kubernetes, un Horizontal Pod Autoscaler (pero probablement encara no necessites Kubernetes).
Les decisions que importen des del dia u
Si hagues de resumir en una llista el que has de fer be des del principi, seria aixo:
- Disseny stateless. Sense estat al servidor d'aplicacio. Sessions a Redis o base de dades, arxius en emmagatzematge extern.
- Emmagatzematge extern de sessions. Mai guardis sessions en memoria del proces. Quan escalis a multiples servidors, un usuari podria anar a un servidor diferent a cada request.
- Estrategia d'indexos. Cada query que faci servir WHERE o ORDER BY necessita un index. Revisa-ho periodicament amb el query planner.
- Separar patrons de lectura i escriptura. Encara que no tinguis read replicas de moment, estructura el teu codi perque sigui facil apuntar lectures a una connexio diferent quan arribi el moment.
- Migracions reversibles. Cada canvi en l'esquema de base de dades ha de poder revertir-se. Aixo no es sobre escalabilitat directament, pero evita downtime quan alguna cosa surt malament en produccio.
El que NO has de fer
Aixo es tan important com l'anterior:
- No facis sharding de la base de dades a 5.000 usuaris. El sharding es complex, introdueix una quantitat enorme de complexitat operacional, i probablement no el necessitaras fins a centenars de milers o milions d'usuaris. PostgreSQL ben configurat gestiona molt mes del que et penses.
- No introdueixis Kubernetes a 10.000 usuaris. K8s resol problemes d'orquestracio a escala. Si tens 3-5 servidors, Docker Compose o un simple load balancer amb instancies es mes que suficient. La complexitat operacional de Kubernetes no es justifica fins que tinguis desenes de serveis.
- No construeixis microserveis abans de tenir 3 equips. Els microserveis son una estrategia organitzacional, no tecnica. Si un sol equip ho manté tot, els microserveis nomes afegeixen latencia de xarxa, complexitat de deploy i dolor de debugging.
- No optimitzis sense mesurar. Cada optimitzacio ha d'estar recolzada per dades. "Crec que la base de dades es lenta" no es suficient. "Aquest query tarda 800ms i s'executa 50.000 vegades al dia" si que ho es.
El checklist abans de cada fase de creixement
Abans de passar a la seguent fase, verifica:
- Tens monitoritzacio que et digui on son els colls d'ampolla reals?
- La teva aplicacio pot correr en multiples instancies sense problemes?
- Les queries mes frequents tenen indexos apropiats?
- Els processos pesats estan fora del cicle request/response?
- Pots fer deploy sense downtime?
- Tens backups automatics i has provat restaurar-los?
El valor de l'experiencia en escalabilitat
La diferencia entre escalar amb dolor i escalar amb confianca es haver passat pel proces abans. Un arquitecte que ja va escalar un sistema de 1.000 a 100.000 usuaris sap quins patrons importen a cada fase i, mes important, quins no importen encara.
A Conectia, els enginyers senior que connectem amb startups europees han passat per 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 teva fase actual, deixant la porta oberta per a la seguent.
Perque escalar no es un event. Es una serie de decisions incrementals. I cadascuna es molt mes facil quan algu al teu equip ja sap quina es la seguent.
El teu producte esta creixent i no saps si la teva arquitectura aguantara el seguent ordre de magnitud? Parla amb un CTO — connectem amb arquitectes que ja han escalat sistemes com el teu.
