Monòlit vs. Microserveis: Quina Arquitectura Triar per al teu MVP
Hi ha una conversa que tinc almenys dues vegades al mes amb fundadors que arriben demanant ajuda amb el seu stack. Comença així: "Volem construir l'MVP amb microserveis des del principi per no haver de reescriure després."
És una idea que sona lògica. I en la gran majoria dels casos, és un error.
L'obsessió amb microserveis ve d'un lloc comprensible. Netflix, Spotify, Amazon — les empreses que més admirem en tecnologia porten anys evangelitzant aquesta arquitectura. Els articles en blogs tècnics, les xerrades a conferències i els fils a Twitter repeteixen el mateix missatge: els monòlits són legacy, els microserveis són el futur.
El que aquests articles no expliquen és que Netflix va començar com un monòlit. Spotify va començar com un monòlit. Amazon va començar com un monòlit. Van migrar a microserveis quan tenien centenars d'enginyers, milions d'usuaris i necessitats d'escalat que un monòlit no podia satisfer. No en la fase d'MVP.
Per què els monòlits guanyen per a MVPs
Un monòlit és una aplicació desplegada com una unitat. Un repositori, un procés, una base de dades. I per a un MVP, això és exactament el que necessites per raons molt concretes:
Velocitat de desenvolupament. En un monòlit, un enginyer pot implementar una funcionalitat end-to-end sense coordinar-se amb altres serveis, sense gestionar comunicació entre processos i sense preocupar-se per consistència de dades distribuïdes. Crides una funció, no un endpoint HTTP. La diferència en velocitat d'iteració és brutal.
Simplicitat de desplegament. Un pipeline de CI/CD. Un servidor (o un contenidor). Un desplegament. No necessites Kubernetes, service mesh, service discovery ni coordinació de versions entre serveis. Quan el teu equip és de 3-5 persones, aquesta simplicitat no és un luxe — és supervivència.
Debugging directe. Quan alguna cosa falla en un monòlit, tens un stack trace. Una ruta clara des de l'error fins a la causa. En microserveis, una fallada pot propagar-se a través de tres serveis diferents, amb logs distribuïts en sistemes diferents, latències de xarxa que enfosqueixen la causa arrel i fallades en cascada que converteixen un bug simple en una investigació d'hores.
Refactoring sense por. En un monòlit, pots moure codi entre mòduls, renombrar funcions i canviar interfícies internes sense trencar contractes d'API entre serveis. El teu IDE et mostra totes les referències. Els teus tests cobreixen el flux complet. En microserveis, un canvi en l'schema d'un event pot trencar tres serveis downstream sense que te n'adonis fins que arriba a producció.
Un sol model de dades. Una base de dades, un schema, una font de veritat. No necessites decidir quin servei és el "propietari" de l'entitat usuari, no necessites sincronitzar dades entre serveis, no necessites eventual consistency quan el teu producte encara està definint quines dades necessita emmagatzemar.
Quan els microserveis sí que tenen sentit
Els microserveis resolen problemes reals. Però són problemes que la majoria d'MVPs no tenen:
Múltiples equips treballant en paral·lel. Si tens 30 enginyers dividits en 6 equips, un monòlit es converteix en un coll d'ampolla. Els conflictes de merge són constants, els desplegaments requereixen coordinació entre equips i un error d'un equip pot bloquejar el release de tots. Microserveis permeten que cada equip desplegui de forma independent.
Necessitats d'escalat diferenciades. El teu servei de processament d'imatges necessita GPUs i escala amb el volum d'uploads. La teva API de cerca necessita molta RAM i escala amb el nombre de queries. El teu servei de notificacions és intensiu en I/O i escala amb els usuaris actius. Si cada component té patrons d'escalat radicalment diferents, desplegar-los per separat permet optimitzar recursos.
Requisits tecnològics diferents per servei. El teu motor de recomanació funciona millor en Python amb ML libraries. La teva API de temps real necessita WebSockets en Node.js. El teu sistema de facturació requereix les garanties transaccionals de Java. Microserveis et permeten triar la tecnologia òptima per a cada domini.
El teu MVP té 30 enginyers? Necessites escalar components de forma independent? Requereixes tres llenguatges de programació diferents? Probablement no. Llavors no necessites microserveis.
El sweet spot: el monòlit modular
La millor decisió per a la majoria de startups no és ni el monòlit clàssic (tot acoblat) ni els microserveis (tot separat). És el monòlit modular.
Un monòlit modular es desplega com una unitat, però internament està organitzat en mòduls amb límits clars. Cada mòdul té la seva pròpia lògica de negoci, els seus propis models de dades i una interfície pública ben definida. Els mòduls es comuniquen a través d'interfícies internes — no crides HTTP, sinó contractes de codi.
Mantens tota la simplicitat del monòlit (un desplegament, una base de dades, debugging directe), però amb la modularitat que necessites per escalar. Quan arribi el moment d'extreure un mòdul com a servei independent, els límits ja estan definits.
La clau és la disciplina. No cridis directament les funcions internes d'un altre mòdul. No comparteixis models de dades entre mòduls. Fes servir la interfície pública. La temptació de prendre dreceres és constant quan tot és al mateix repositori — i aquí és on un enginyer sènior amb experiència en arquitectura marca la diferència.
Els costos reals dels microserveis prematurs
Si encara estàs temptat pels microserveis per al teu MVP, considera els costos que rarament apareixen als articles que els promocionen:
Complexitat de DevOps. Cada servei necessita el seu propi pipeline de CI/CD, la seva pròpia configuració de desplegament, el seu propi monitoratge. Amb 5 microserveis, tens 5 pipelines que mantenir. Amb un monòlit, en tens un.
Overhead d'infraestructura. Kubernetes, service mesh, logging centralitzat, tracing distribuït, health checks per servei. Res d'això és gratis — ni en diners ni en temps d'enginyeria.
Latència de xarxa. El que abans era una crida a funció en memòria (nanosegons) ara és una crida HTTP o gRPC (mil·lisegons). Multiplica-ho per cada interacció entre serveis en un request de l'usuari.
Consistència de dades. Amb una base de dades per servei perds transaccions ACID entre serveis. Necessites sagas o eventual consistency. Per a un MVP que encara està definint el seu model de dades, això és complexitat prematura.
Debugging distribuït. Un bug que en un monòlit es diagnostica en 15 minuts pot trigar mig dia en microserveis. L'error es va originar al servei A, es va propagar al B i l'usuari el va veure al C. Sense tracing distribuït ben configurat, estàs navegant a cegues.
Un framework de decisió simple
Abans de triar arquitectura, respon aquestes preguntes:
- El teu equip té menys de 8 enginyers? --> Monòlit.
- Estàs construint un sol producte? --> Monòlit.
- Ets en fase pre-seed, seed o Sèrie A primerenca? --> Monòlit.
- La teva prioritat és velocitat d'iteració i time-to-market? --> Monòlit.
- Pots assumir el cost d'un equip de DevOps dedicat? --> Si no, monòlit.
Si has respost "monòlit" a tot: construeix un monòlit modular amb límits clars entre mòduls. Quan tinguis 20+ enginyers, múltiples equips i necessitats d'escalat diferenciades, estaràs en posició d'extreure serveis de forma incremental — sense reescriure des de zero.
Com dissenyar un monòlit que sigui fàcil de descompondre després
Si acceptes que el monòlit és la decisió correcta avui, la següent pregunta és com evitar que es converteixi en una bola de fang impossible de descompondre quan arribi el moment. Aquestes són les pràctiques que funcionen:
- Organitza el codi per domini de negoci, no per capa tècnica. En lloc de carpetes
/controllers,/models,/services, fes servir/billing,/users,/notifications. Cada domini conté els seus propis controladors, models i serveis. - Defineix interfícies explícites entre mòduls. Cada mòdul exposa una API interna (funcions, classes, interfícies) i oculta la seva implementació. Cap mòdul accedeix directament a la base de dades d'un altre.
- Una base de dades, però schemas separats. Fes servir schemas o prefixos de taula per separar les dades de cada mòdul. Això facilita l'extracció futura.
- Evita dependències circulars. Si el mòdul A depèn de B i B depèn d'A, tens un problema de disseny que serà molt pitjor quan intentis separar-los.
- Tests per mòdul. Cada mòdul té els seus propis tests unitaris i d'integració. Si pots testejar un mòdul de forma aïllada, pots extreure'l de forma aïllada.
Aquestes pràctiques no requereixen més temps de desenvolupament. Requereixen més disciplina de disseny. I aquesta disciplina és el que distingeix un enginyer sènior d'un júnior — no el framework que fa servir, sinó com estructura el codi perquè l'equip que vingui després pugui treballar-hi.
A Conectia, els enginyers sènior que proporcionem a startups europees han construït i descompost monòlits en empreses de totes les mides. No arriben amb una opinió dogmàtica sobre monòlits vs. microserveis — arriben amb l'experiència per avaluar el teu cas concret i prendre la decisió correcta. Perquè l'arquitectura correcta no és la que està de moda. És la que et permet lliurar valor a l'usuari tan ràpid com sigui possible amb l'equip que tens avui.
No tens clar quina arquitectura necessita el teu producte? Parla amb un CTO — avaluem el teu cas i et recomanem l'arquitectura que s'ajusta a la teva etapa i al teu equip.
