Del monolito a las APIs: cuándo merece la pena partir tu sistema
Los microservicios se han convertido en la respuesta por defecto a cualquier problema de escala. Casi siempre es una respuesta equivocada, y explicamos cómo saber si es la tuya.
Cada cierto tiempo alguien nos pide partir su aplicación en microservicios. Cuando preguntamos qué problema quiere resolver, la respuesta suele ser difusa. Y sin un problema concreto, partir un sistema solo multiplica las piezas que pueden fallar.
Lo que realmente cuesta un sistema distribuido
En un monolito, dos partes del código se llaman entre sí y punto. En cuanto las separas, esa llamada pasa por la red: puede fallar, tardar o repetirse. Aparecen problemas que antes no existían: transacciones repartidas entre servicios, versiones que deben convivir, y un error que ahora hay que perseguir por cinco registros distintos.
Todo eso se resuelve, pero cuesta dinero y exige un equipo preparado para operarlo.
Cuándo sí compensa separar
- Una parte tiene una carga muy distinta al resto. Si el procesado de imágenes consume el servidor mientras el resto está ocioso, separarlo permite escalar solo eso.
- Varios equipos se pisan. Cuando el cuello de botella es organizativo, separar por dominios acelera de verdad.
- Ritmos de cambio incompatibles. Una pieza que cambia a diario y otra que se toca una vez al año no tienen por qué desplegarse juntas.
- Requisitos distintos de disponibilidad. Aislar lo crítico evita que un fallo secundario lo tumbe todo.
El paso intermedio que casi siempre basta
Antes de partir nada, se puede ordenar por dentro: separar el código en módulos con fronteras claras, cada uno dueño de sus datos y comunicándose por interfaces explícitas. Es lo que se conoce como monolito modular.
Se despliega como una sola aplicación, así que evitas toda la complejidad de operar muchos servicios, pero dejas el sistema preparado para extraer una pieza el día que haya una razón real. Muchos de los problemas que llevan a pedir microservicios se resuelven aquí, junto con revisar las consultas a base de datos y añadir caché donde toca.
Empieza por la API
Si tu objetivo es que otros sistemas se integren contigo, o abrir tu producto a terceros, el trabajo no es partir el sistema: es diseñar una buena API. Contratos claros, versionado, autenticación sólida, límites de uso y documentación que se mantenga al día.
Cómo lo hacemos
Auditamos el sistema, medimos dónde está el problema y proponemos el cambio más pequeño que lo resuelve. A veces es un índice en la base de datos; otras, extraer un servicio. Lo que no hacemos es reescribir un sistema entero porque sí.
Cuéntanos qué se te está atragantando —lentitud, caídas, despliegues imposibles— y lo miramos.