Definición rápida
Los microservicios son un estilo de arquitectura de software donde una aplicación se construye como un conjunto de servicios pequeños, independientes y especializados, cada uno responsable de una única función de negocio (catálogo, inventario, precios, órdenes), que se comunican entre sí mediante APIs. Cada microservicio se despliega, escala y actualiza por separado, sin depender del ciclo de vida de los demás.
¿Qué significa?
La alternativa histórica a los microservicios es la arquitectura monolítica: una sola aplicación donde todas las funciones —catálogo, carrito, pagos, contenido— comparten el mismo código base, la misma base de datos y el mismo proceso de despliegue. En un monolito, un cambio pequeño en el módulo de precios requiere volver a desplegar la aplicación completa, incluidas partes que no cambiaron.
Los microservicios rompen esa unidad artificial. Cada servicio tiene su propio código, con frecuencia su propia base de datos, y se comunica con otros servicios exclusivamente mediante APIs bien definidas —nunca accediendo directamente a la base de datos interna de otro servicio. Esto significa que un equipo puede desplegar una nueva versión del servicio de inventario sin coordinar con el equipo que mantiene el checkout.
El tamaño de un microservicio no se mide en líneas de código, sino en responsabilidad: un microservicio bien diseñado hace una cosa, la hace bien, y expone esa capacidad a través de una interfaz clara. Cuando un servicio empieza a acumular múltiples responsabilidades no relacionadas, deja de ser "micro" en el sentido arquitectónico, sin importar su tamaño real.
¿Por qué es importante?
En un monolito, escalar una sola función que recibe alta demanda (por ejemplo, búsqueda durante una campaña) obliga a escalar toda la aplicación, incluidas partes que no lo necesitan, lo que desperdicia recursos. Los microservicios resuelven ese problema: cada servicio escala de forma independiente según su propia demanda.
También resuelven un problema organizacional: en equipos grandes, un monolito se convierte en un cuello de botella de coordinación, porque cualquier cambio requiere pruebas sobre todo el sistema. Con microservicios, equipos distintos pueden trabajar, desplegar y fallar de forma aislada sin bloquearse mutuamente.
¿Cómo funciona?
Cada microservicio se empaqueta típicamente como un contenedor independiente, con su propia lógica y, con frecuencia, su propia base de datos —lo que evita que un servicio dependa directamente del esquema interno de otro. La comunicación ocurre mediante llamadas API síncronas (REST, GraphQL) o mensajería asíncrona (colas de eventos) cuando la operación no requiere respuesta inmediata.
Un orquestador de contenedores (habitualmente Kubernetes, en entornos cloud native) gestiona el despliegue, escalado y recuperación de cada servicio. Una capa de descubrimiento de servicios permite que cada microservicio encuentre a los demás sin direcciones fijas, y un API gateway suele centralizar la entrada de tráfico externo hacia el conjunto de servicios.
Ejemplo aplicado a AI Commerce
Un retailer separa su motor de recomendaciones con IA en un microservicio independiente del resto de la plataforma. Cuando el modelo de recomendación necesita actualizarse —por ejemplo, para incorporar un nuevo algoritmo de personalización basado en embeddings— el equipo despliega esa versión únicamente al microservicio de recomendaciones. El catálogo, el checkout y el inventario continúan operando sin interrupción, porque no comparten proceso ni ciclo de despliegue con el servicio actualizado.
Conceptos relacionados
Los microservicios son una de las cuatro condiciones de MACH, y la unidad de despliegue natural de una infraestructura Cloud Native. Dependen de API First para que la comunicación entre servicios sea estable y predecible. Son también el fundamento técnico de Composable Commerce, donde cada capacidad de negocio se implementa como uno o varios microservicios independientes.
Errores comunes
Se asume que "microservicio" significa simplemente "servicio pequeño en tamaño de código". El criterio correcto es la responsabilidad única y el desacople, no el número de líneas. También se subestima la complejidad operativa: pasar de un monolito a decenas de microservicios introduce necesidad de observabilidad distribuida, gestión de fallos en cascada y coordinación de versiones que no existían antes. Por último, se confunde microservicios con arquitectura "sin base de datos compartida" de forma absoluta: en migraciones progresivas es común convivir temporalmente con bases de datos compartidas mientras se completa la separación.
Perspectiva de Edgebound Labs
En el laboratorio, la pregunta antes de dividir un monolito en microservicios no es "¿cuántos servicios podemos crear?", sino "¿qué límite de responsabilidad realmente existe en este sistema?". Migrar sin ese mapeo previo genera microservicios mal delimitados, con dependencias ocultas que reproducen los problemas del monolito, solo que distribuidos. El método —mapear dependencias antes de mover código— es lo que separa una migración exitosa de una reescritura fallida.
Preguntas frecuentes sobre microservicios
¿Cuál es la diferencia entre microservicios y monolito?
Un monolito comparte código, base de datos y despliegue entre todas sus funciones. Los microservicios separan cada función en un servicio independiente con su propio ciclo de vida.
¿Todo microservicio necesita su propia base de datos?
No es obligatorio, pero es una buena práctica común para evitar acoplamiento oculto entre servicios.
¿Los microservicios siempre son mejores que un monolito?
No. Para equipos pequeños o sistemas de baja complejidad, un monolito bien diseñado puede ser más simple de operar y mantener.
¿Qué papel juega Kubernetes aquí?
Kubernetes orquesta el despliegue, escalado y recuperación de los contenedores que ejecutan cada microservicio, típicamente en infraestructura cloud native.
¿Los microservicios se comunican siempre por API REST?
No siempre. También se usa GraphQL para consultas flexibles y mensajería asíncrona (colas de eventos) para comunicación que no requiere respuesta inmediata.
¿Es lo mismo que arquitectura orientada a servicios (SOA)?
Comparten principios de desacople, pero los microservicios son más granulares y suelen desplegarse de forma completamente independiente, sin un bus de servicios centralizado.
Sigue explorando el glosario
¿Aplicando microservicios en tu operación?
Hacemos un diagnóstico de tu stack de comercio y te decimos qué necesitas para escalar con IA — sin slides genéricos, con métricas de éxito definidas.