Hace unos meses arranqué a construir BlackStar, un accounting engine multitenant en Rails 8. Y antes de escribir una sola línea de código, tuve que tomar una decisión que en 2022 habría respondido diferente: ¿cómo estructuro esto?
La respuesta de 2022 habría sido automática: microservicios, Kubernetes, un servicio por dominio, event sourcing, la obra completa. Porque así lo hace Netflix. Porque así se escala. Porque así se ve "serio" en el whiteboard.
La respuesta de 2026 es diferente. Y creo que vale la pena hablar de por qué.
Lo que la industria aprendió a las malas
Existe un reporte de CNCF de 2025 que me parece honesto: el 42% de organizaciones que adoptaron microservicios están consolidando sus servicios de vuelta. No porque la tecnología fallara. Sino porque el costo operativo no se justificó.
Twilio Segment lo documentó públicamente: colapsaron 140+ microservicios en un monolito después de que tres ingenieros de tiempo completo pasaban la mayoría de su tiempo apagando incendios de infraestructura en lugar de construir producto.
Amazon Prime Video redujo sus costos de infraestructura en un 90% migrando su servicio de monitoreo de video de una arquitectura distribuida a un proceso único.
No digo esto para romantizar el monolito. Lo digo porque la narrativa de "microservicios = moderno, monolito = legacy" fue simplificada al punto de ser dañina para equipos pequeños y medianos.
La pregunta correcta nunca fue ¿microservicios o monolito? La pregunta correcta es: ¿qué arquitectura se alinea con mi contexto actual?
Mi contexto: BlackStar y RavnPro
BlackStar es un accounting engine multitenant construido en Rails 8. El primer consumidor es RavnPro, un ERP para talleres de llantas.
Cuando digo "accounting engine" quiero decir: 34 service objects, un esquema de base de datos con multitenancy via acts_as_tenant + Row-Level Security en PostgreSQL 16, webhooks, una API REST completa, y un frontend Hotwire + Tailwind.
No es una app pequeña. Pero tampoco es un sistema que necesite 50 ingenieros operando servicios independientes.
Entonces elegí un Modular Monolith.
Qué significa Modular Monolith en la práctica
Un Modular Monolith no es un monolito desordenado donde todo llama a todo. Tampoco es microservicios en el mismo proceso.
Es un monolito donde los módulos tienen fronteras explícitas.
En BlackStar, cada dominio vive en su propio namespace:
app/ services/ accounting/ journal_entries/ chart_of_accounts/ reporting/ inventory/ billing/ tenancy/ models/ controllers/
Los service objects no llaman directamente a modelos de otro dominio. Si Billing necesita datos de Inventory, pasa por una interfaz definida. Esto no lo hace una arquitectura de microservicios — sigue siendo un solo deployment, una sola base de datos — pero la disciplina en las fronteras me permite, en el futuro, extraer un módulo a un servicio independiente si el negocio lo justifica.
El módulo se convierte en el incubador del futuro servicio. Pero solo si ese momento llega.
La tendencia más importante de 2026: el regreso al pragmatismo
Hay algo que está pasando en la industria que me parece saludable: el pragmatismo le está ganando al dogma.
GitHub, Shopify y Basecamp escalan con Rails monolítico. Shopify sirve millones de transacciones con una arquitectura que muchos considerarían "anticuada". No porque no sepan hacer microservicios — sino porque saben cuándo no usarlos.
El consenso que está emergiendo en 2026 es algo así:
- Monolito modular como punto de partida
- 2 a 5 servicios extraídos para hot paths que genuinamente lo necesitan (AI, pagos, notificaciones)
- Extracción cuando el negocio lo justifica, no cuando la arquitectura teórica lo sugiere
En el caso de BlackStar + RavnPro, ese hot path podría ser en algún momento el motor de parsing de facturas via AI. Hoy, ese módulo vive dentro del monolito. Cuando el volumen lo requiera, tiene fronteras lo suficientemente limpias para ser extraído.
Lo que sí cambió: Agentic AI como arquitectura
Una cosa que 2026 sí trajo de nuevo: los sistemas se están diseñando desde el principio para alojar agentes autónomos con estado y memoria.
En RavnPro, ya existe un módulo que procesa órdenes de compra desde correos usando Groq como parser primario y Gemini como backup. Eso no era una feature de un ERP hace tres años.
El punto no es que todos tengamos que integrar AI. El punto es que la arquitectura de datos cambia cuando tus flujos de trabajo incluyen modelos de lenguaje: necesitas trazabilidad, necesitas rollbacks semánticos, necesitas pensar en el contexto como un ciudadano de primera clase en tu schema.
BlackStar está diseñado para esto. Cada operación contable genera un journal entry inmutable con metadata completo. No porque sepa exactamente qué agente la va a necesitar — sino porque es la decisión arquitectónica correcta para un sistema que manejará dinero de negocios reales.
La filosofía que aplico en mi código
Después de nueve años escribiendo Rails, hay principios que resisten el paso del tiempo:
1. Empieza simple, evoluciona deliberadamente. Los productos no fracasan por falta de escalabilidad. Fracasan por falta de product-market fit. La arquitectura más inteligente es la que te permite aprender rápido.
2. El costo real no es el cómputo, son los ingenieros. Un monolito modular puede necesitar 1-2 ingenieros de operaciones. Un sistema equivalente en microservicios necesita 2-4 platform engineers dedicados, más overhead distribuido en todos los equipos. A $150,000+ por ingeniero, esa decisión no es técnica, es financiera.
3. Claridad explícita sobre magia implícita. Me gusta Rails precisamente porque tiene convenciones fuertes. Pero cuando escribo un service object, quiero que cualquier persona que lo lea en seis meses entienda qué hace sin tener que rastrear callbacks en cuatro modelos.
4. Boundaries antes que abstracciones. Un módulo con una interfaz clara es más valioso que una abstracción genial. Las fronteras disciplinan mejor que los patrones.
5. Diseña para la operación desde el día uno. Logging a STDOUT desde el primer commit. Trazas completas en cada operación. Sidekiq con queues nombradas por dominio. Si no puedes debuggear en producción a las 2am sin llorar, el diseño tiene un problema.
El stack concreto de BlackStar en 2026
Para los que prefieren lo concreto sobre lo conceptual:
- Rails 8 — Hybrid monolith con Hotwire. Sin SPA separado, sin el overhead de una API para el frontend propio.
- PostgreSQL 16 —
acts_as_tenant+ Row-Level Security para multitenancy.DECIMAL(12,2)para dinero. Nunca floats. - Sidekiq + Redis — Procesamiento asíncrono con queues por dominio.
- Devise + JWT — Auth para web y API en el mismo sistema.
- Pundit — Autorización granular con policies por recurso.
- DaisyUI + Tailwind — UI components compatibles con Hotwire/Stimulus.
- Resend — Email transaccional.
No hay Kubernetes. No hay service mesh. No hay API gateway. No hay 23 repos.
Hay un repo, un deployment, y fronteras de módulo que se respetan por disciplina.
Lo que aprendí construyendo esto
La decisión más importante en BlackStar no fue técnica. Fue de humildad.
Humildad para reconocer que no soy Netflix, no tengo 200 ingenieros, y que mis clientes necesitan que el software funcione correctamente antes de que necesiten escalar a un millón de usuarios.
La arquitectura correcta no es la más impresionante en un whiteboard. Es la que le permite a un equipo pequeño mover rápido, debuggear fácil y dormir tranquilo.
En 2026, esa arquitectura tiene nombre: Modular Monolith. Y resulta que Rails lleva haciendo esto bien más de diez años.
¿Tienes preguntas sobre la arquitectura o quieres discutir las decisiones de diseño? Escríbeme en @devrafaeldelgado.