Escrito por Rodrigo de Miguel
Por qué no monté microservicios para mi SaaS
(y cómo eso me permitió lanzar antes y ayudar más)
En ADOPTA elegí no montar microservicios porque el problema no era la escalabilidad, sino lanzar rápido con el mínimo coste y mantenimiento en un proyecto mantenido por una sola persona. Un monolito modular me dio límites claros, mejor DX y foco en impacto real: ayudar a más refugios y facilitar más adopciones.
El problema nunca fue técnico
ADOPTA nació con una idea muy clara: facilitar y fomentar la adopción de animales.
Es un SaaS gratuito tanto para refugios como para particulares. No hay paywalls, no hay planes premium, no hay MRR que optimizar.
Eso cambia completamente las reglas del juego.
El objetivo no era maximizar ingresos, sino maximizar impacto:
- Más refugios usando la plataforma.
- Más adopciones reales.
- Menos fricción operativa para gente que ya va justa de recursos.
Desde el primer día, la restricción principal no fue la escalabilidad futura ni la elegancia arquitectónica. Fue otra mucho más básica y real:
Había que lanzar algo usable cuanto antes, con el mínimo coste y el mínimo mantenimiento posible.
Y eso, inevitablemente, condiciona todas las decisiones técnicas.
El equipo: una realidad incómoda, pero muy común
Conviene dejar esto claro desde el principio, porque afecta a todo lo demás.
ADOPTA no lo construyó un “equipo backend”.
Lo construí yo solo.
Al principio empecé con un buen amigo (un saludo Tomy 😊👋) recién salidos de la universidad:
- Él hacía frontend.
- Yo backend.
Pero esa situación duró poco. El proyecto siguió, pero el equipo pasó a ser una sola persona.
Sin DevOps.
Sin SRE.
Sin nadie a quien pasarle el marrón cuando algo fallaba.
Esto no es una queja. Es el contexto real desde el que se toman decisiones sensatas.
El mito: “Si es un SaaS, tiene que ser microservicios”
Hay una asociación automática que se repite mucho:
SaaS = microservicios = arquitectura seria
Y es una asociación peligrosa.
Porque mezcla tres cosas distintas:
- Modelo de negocio
- Forma de despliegue
- Calidad del diseño interno
Un monolito no es sinónimo de código malo.
Un microservicio no es sinónimo de código bueno.
Un monolito es, simplemente, todo el código desplegado como una unidad.
La mala fama del monolito viene de otra cosa:
sistemas donde nadie pensó en arquitectura, límites o mantenibilidad. Eso no es un problema del monolito. Es un problema de criterio técnico.
El punto de partida real: un monolito clásico (y honesto)
Aquí va una parte importante del aprendizaje:
ADOPTA no empezó como monolito modular.
Empezó como monolito clásico.
Y fue una decisión consciente.
En ese momento:
- El dominio estaba verde.
- Las funcionalidades cambiaban cada semana.
- No había certeza de qué iba a sobrevivir.
Optimizar arquitectura demasiado pronto habría sido perder tiempo.
El objetivo era:
- Entender el problema.
- Validar flujos.
- Ver cómo usaban la plataforma los refugios.
Aprender y nada más.
La deuda técnica apareció (como siempre)
Con el tiempo, pasó lo inevitable:
- El código creció.
- Aparecieron dependencias incómodas.
- Algunas decisiones rápidas empezaron a pasar factura.
Pero aquí viene la diferencia importante:
La deuda técnica no apareció por usar un monolito.
Apareció porque el producto evolucionó.
Eso iba a pasar igual con microservicios, solo que:
- Habría sido más caro.
- Más difícil de cambiar.
- Más lento de entender.
El fork técnico real: qué hacer con esa deuda
Llegó un punto claro de decisión:
Opción A: “Ya que estamos, rompemos en microservicios”
La tentación clásica.
Problema:
- Infra más compleja.
- Coste operativo mayor.
- Debug distribuido.
- Mucha inversión para un proyecto sin ROI económico.
Opción B: Refactorizar a un monolito modular
Menos sexy. Mucho más pragmático.
- Un solo despliegue.
- Un solo runtime.
- Mejor diseño interno.
- Menos fricción diaria.
Elegí la opción B.
Importante: no uso DDD (y no pasa nada)
Otro punto que conviene aclarar porque suele generar ruido.
En ADOPTA:
- No se usa Domain-Driven Design formal.
- No hay aggregates, value objects ni bounded contexts “de libro”.
Lo que sí se usa es:
- Screaming Architecture: la estructura del proyecto grita qué hace el sistema.
- Principios de MVC (Modelo-Vista-Controlador) + SRP (Single Responsibility Principle):
- Dominio independiente.
- Capas claras.
- Infraestructura reemplazable.
Esto fue una decisión consciente para evitar:
- Sobrecarga conceptual.
- Ceremonia innecesaria para un proyecto de una sola persona.
Qué significa aquí “monolito modular”
No significa carpetas bonitas.
Significa límites claros y respetados, aunque todo se despliegue junto.
Principios clave
- Cada área funcional vive en su propio módulo.
- El dominio no conoce frameworks.
- No se comparten modelos “por comodidad”.
- La base de datos no dicta la arquitectura.
Ejemplo conceptual:
TEXT/adoptions controllers/ repositories/ services/ /shelters controllers/ repositories/ services/ /users controllers/ repositories/ services/ /shared
La diferencia con el monolito inicial no fue tecnológica. Fue disciplinaria.
Por qué los microservicios habrían sido una mala idea aquí
Con una sola persona manteniendo el sistema:
- Cada microservicio es otro sistema que entender.
- Cada despliegue es otro punto de fallo.
- Cada error distribuido cuesta más tiempo mental.
Y aquí entra una frase clave que resume la decisión:
Los microservicios son una optimización prematura cuando no tienes un problema de escalado real.
ADOPTA no tenía problemas de throughput. Tenía problemas de tiempo, foco y energía (y personal 🐣).
El coste oculto de los microservicios: todo es una interfaz
Hay un detalle que parece menor, pero en la práctica lo cambia todo:
los microservicios no se comunican con funciones, se comunican con interfaces.
REST APIs, colas, eventos, topics, contratos versionados.
Todo eso es necesario en un sistema distribuido, pero no es gratis.
En un monolito, un flujo es:
llamar a una función
En microservicios, ese mismo flujo es:
- serializar datos
- enviarlos por red
- deserializarlos
- manejar timeouts
- tratar errores parciales
- versionar contratos
Eso introduce complejidad técnica y cognitiva.
Developer Experience: cuando el código es la documentación
En un monolito modular bien diseñado:
- La documentación es el propio código.
- El IDE entiende todo el sistema.
- El autocompletado del IDE te guía.
- Navegar entre llamadas es inmediato.
Puedes:
- saltar a la definición
- ver tipos reales
- refactorizar con seguridad
No necesitas:
- Swagger para entender qué pasa
- Postman para probar un flujo interno
- Documentación externa para no romper nada
Todo está ahí, vivo, coherente.
Recuerda, es un sistema mantenido por una sola persona que empezó como junior.
Cuando el coste no es técnico, es mental
Con una sola persona manteniendo el sistema, esto es crítico.
Cada interfaz externa añade:
- fricción
- contexto que cargar en la cabeza
- tiempo perdido entendiendo contratos
En un proyecto como ADOPTA, donde:
- no hay equipos separados
- no hay SLAs internos
- no hay necesidades reales de aislamiento
Usar microservicios habría sido empeorar el DX sin ningún beneficio tangible.
Menos interfaces, más foco
Reducir el número de interfaces no es pereza técnica.
Es una forma muy eficaz de:
- reducir bugs
- acelerar cambios
- mantener el sistema vivo con menos energía
Y cuando el objetivo es impacto social, no escalabilidad teórica, ese foco importa más que cualquier diagrama bonito.
Infraestructura: menos es más
La infra de ADOPTA es deliberadamente simple:
- Un backend.
- Un despliegue.
- Un pipeline.
- Una base de datos bien diseñada.
Nada de:
- Kubernetes.
- Service mesh.
- Observabilidad avanzada “por si acaso”.
Cada pieza extra habría sido:
- Más coste.
- Más mantenimiento.
- Más riesgo para un proyecto altruista.
El ROI aquí no es dinero (y eso importa)
Este es un punto fundamental.
El ROI de ADOPTA no se mide en euros. Se mide en:
- Número de adopciones facilitadas.
- Tiempo que los refugios ahorran en gestión.
- Número de refugios activos.
Elegir una arquitectura simple permitió:
- Mantener costes bajos.
- No depender de financiación externa.
- Sostener el proyecto en el tiempo.
Eso también es ROI, aunque no salga en una hoja de cálculo financiera.
La deuda técnica, revisitada con perspectiva
El refactor a monolito modular fue, en sí mismo, pagar deuda técnica.
Pero no se hizo:
- Todo de golpe.
- Ni antes de tiempo.
- Ni por “pureza”.
Se hizo cuando:
- El dominio empezó a estabilizarse.
- El dolor era real.
- El beneficio estaba claro.
La deuda técnica bien gestionada no frena proyectos. Los acelera.
Qué podría salir mal (y cómo evitarlo)
Riesgos del monolito modular
- Relajar fronteras.
- “Ya que estamos” compartir código.
- Volver al espagueti poco a poco.
Mitigaciones reales
- Revisión constante de dependencias.
- Refactors pequeños y frecuentes.
- Decisiones conscientes, no automáticas.
¿Y si algún día hace falta escalar?
La pregunta inevitable.
La respuesta honesta es:
Cuando llegue ese día, el sistema estará mucho mejor preparado que si hubiese empezado con microservicios.
Porque:
- Los dominios están claros.
- Las dependencias están controladas.
- Extraer un módulo sería posible.
Si no puedes hacer eso, no tenías microservicios. Tenías un monolito distribuido.
Mi lección
La arquitectura no es una competición de complejidad.
Es un medio para:
- Resolver problemas reales.
- Con recursos reales.
- En contextos imperfectos.
Elegir un monolito (y evolucionarlo bien) no es falta de ambición. Es criterio.
Y ese criterio es lo que permite que proyectos como ADOPTA existan, se mantengan y ayuden de verdad.
No montar microservicios no fue una renuncia. Fue una decisión consciente alineada con el propósito del proyecto.
ADOPTA existe hoy porque la arquitectura no se comió al producto.
Y esa, muchas veces, es la decisión más senior que puedes tomar.
