Modelo de Microservicios

Arquitectura de Software - Microservicios

El modelo de microservicios propone construir una aplicación como un conjunto de servicios pequeños, autónomos y especializados. Cada microservicio se encarga de una funcionalidad específica, se despliega de forma independiente y comunica con los demás a través de APIs bien definidas.

¿De dónde viene esta idea?

La necesidad de escalar sistemas complejos, mantener equipos independientes y mejorar los tiempos de desarrollo impulsó el surgimiento de esta arquitectura. Grandes empresas como Netflix, Amazon o Spotify la adoptaron para dividir sus sistemas monolíticos en servicios distribuidos.

Características clave

• Descomposición por funcionalidades o dominios.
• Cada microservicio tiene su propia base de datos (independencia de datos).
• Se comunican vía HTTP/REST, gRPC, eventos u otros mecanismos.
• Escalables, desplegables y versionables de forma independiente.

Analogía cotidiana

Imaginá un shopping. Hay una tienda de ropa, una librería, una heladería. Cada negocio tiene su equipo, su caja, su inventario. Si una tienda cierra, el shopping sigue funcionando. Así son los microservicios: independientes pero colaborando.

Ventajas

• Permite escalar partes específicas de una app según demanda.
• Facilita el trabajo de equipos pequeños y autónomos.
• Despliegues más seguros: un fallo no afecta a toda la app.
• Permite diversidad tecnológica (Java, Node.js, Python…).

Desventajas

• Mayor complejidad operativa (infraestructura, monitoreo, trazabilidad).
• Depende fuertemente de una buena arquitectura de comunicación.
• Posibilidad de duplicar lógica o inconsistencias entre servicios.
• Requiere automatización: CI/CD, orquestadores, balanceadores, etc.

Ejemplo técnico (Arquitectura realista)

Supongamos que estamos desarrollando un sistema de e-commerce. Usamos microservicios para dividirlo en componentes independientes. A continuación, se muestra cómo podría verse esto:

• Servicio de Catálogo: expone productos disponibles, precios, descripciones.
• Servicio de Carrito: administra productos añadidos por el usuario antes de comprar.
• Servicio de Pedidos: recibe pedidos desde el carrito, procesa pagos, genera confirmaciones.
• Servicio de Usuarios: maneja autenticación, perfiles, direcciones de envío.

Cada uno de estos servicios está desacoplado, tiene su propia base de datos y puede desplegarse en servidores separados. Se comunican por HTTP o mensajería asincrónica. Si el carrito falla, el catálogo y el login siguen funcionando normalmente.

Fragmentos de código por servicio

// Servicio de Catálogo (Node.js + Express)
const express = require('express');
const app = express();

app.get('/catalogo', (req, res) => {
  res.json([ { id: 1, nombre: 'Zapatilla', precio: 10000 }, { id: 2, nombre: 'Campera', precio: 25000 } ]);
});

app.listen(3001, () => console.log('Servicio de Catálogo corriendo en 3001'));

// Servicio de Carrito (Node.js + Express)
const express = require('express');
const app = express();

let carrito = [];

app.post('/carrito', (req, res) => {
  const producto = req.body;
  carrito.push(producto);
  res.status(201).send('Producto agregado al carrito');
});

app.listen(3002, () => console.log('Servicio de Carrito corriendo en 3002'));

// Servicio de Pedidos (Node.js + Express)
const express = require('express');
const app = express();

app.post('/pedido', (req, res) => {
  // Acá se registraría el pedido y se llamaría al gateway de pago
  res.send('Pedido procesado correctamente');
});

app.listen(3003, () => console.log('Servicio de Pedidos corriendo en 3003'));

// Servicio de Usuarios (Node.js + Express)
const express = require('express');
const app = express();

app.get('/usuarios/:id', (req, res) => {
  const id = req.params.id;
  res.json({ id, nombre: 'Juan', email: 'juan@example.com' });
});

app.listen(3004, () => console.log('Servicio de Usuarios corriendo en 3004'));

Este enfoque permite que distintos equipos trabajen en paralelo, desplegar funcionalidades nuevas sin afectar al sistema completo y escalar servicios individuales según necesidad.

¿Cuándo conviene usarlos?

Cuando un sistema crece mucho en funcionalidades, equipos y volumen de usuarios. También cuando necesitás escalar ciertas partes más que otras o usar tecnologías distintas en cada módulo.

Conclusión

Los microservicios no son para todos. Son poderosos pero complejos. Si tu equipo y contexto lo permiten, ofrecen una gran ventaja a largo plazo. Pero si estás comenzando, tal vez un monolito bien hecho sea el mejor punto de partida.