Composable commerce Cambie piezas. No toda la tienda.

Composable commerce significa que búsqueda, PIM, CMS o lógica de precios funcionan como servicios propios conectados por APIs. Los sacamos uno a uno de su tienda actual, donde compensa, y dejamos el resto funcionando.

Hablar de la arquitectura

Cuándo compensa

No todo monolito hay que desmontarlo.

Merece la pena si

  • una parte de la tienda frena constantemente, como la búsqueda o los datos de producto,
  • varios equipos deben publicar de forma independiente,
  • quiere cambiar una pieza sin tocar el resto.

Mejor no, si

  • su tienda funciona estable y cambia poco,
  • no hay nadie para operar cinco servicios en lugar de uno.

¿Monolito? Queda muy bien en un museo.

Sacamos una pieza tras otra. Mientras tanto, la tienda sigue funcionando.

Hablar de la arquitectura
Bloque de hormigón junto a bloques de madera de colores

Estructura típica

Cuatro capas. Los productos los elige usted.

  • Experiencia

    Frontend headless o PWA, CMS, búsqueda, personalización.

  • Servicios de dominio

    Carrito y checkout, precios y promociones, catálogo y PIM, pedidos.

  • Datos

    Eventos entre servicios, data warehouse, servicios de IA.

  • Infraestructura

    API gateway, permisos, caché en el borde, monitorización de todos los servicios.

Magento puede seguir siendo uno de los servicios, por ejemplo para precios, clientes y pedidos.

Conexiones

Desacoplar es fácil. Conectar de forma fiable es el trabajo.

  • Eventos en lugar de llamadas directas

    Si cambia un precio en el ERP, la tienda se entera por un evento. Si un servicio cae un momento, no se pierde nada.

  • Flujos con reintentos

    Pedidos, aprobaciones y devoluciones funcionan como flujos con límites de tiempo, reintentos y pasos manuales donde haga falta.

  • Una sola entrada para el frontend

    Un API gateway gestiona autenticación y límites y da a cada canal la respuesta que necesita.

  • Contratos entre servicios

    Cada interfaz está descrita y probada. Un cambio en el servicio A no rompe el B sin que nadie lo note.

Operación

Sin responsables claros la modularidad se vuelve caos.

  1. Un dueño por servicio

    Con manual de operación y vía de escalado. Nada de «eso no lo hace nadie».

  2. Tests de contrato

    Se ejecutan en cada release y muestran si un cambio afecta a otro servicio.

  3. Rollback seguro

    Feature flags y releases graduales, para que un error solo afecte a parte de los usuarios.

  4. Presupuestos por interfaz

    Tiempo de respuesta y coste tienen un límite. Si se supera, avisa la monitorización.

Preguntas frecuentes

Lo que los equipos quieren saber antes.

¿En qué se diferencia de un monolito?
Un monolito reúne catálogo, checkout, búsqueda y CMS en un solo software. Con composable, cada servicio hace una tarea y habla con los demás por APIs. Así se puede cambiar o escalar una parte sin tocar el resto.
¿Hay que reconstruir toda la tienda?
No. Normalmente se empieza por un solo servicio, por ejemplo la búsqueda o el PIM. El resto de la tienda sigue funcionando mientras el nuevo servicio toma el relevo poco a poco.
¿Cuándo compensa?
Cuando varios equipos trabajan en la tienda y se bloquean entre sí, o cuando una parte del sistema frena todo lo demás. Para una tienda pequeña y estable suele ser demasiado.
¿Cuánto dura la transformación?
Depende de qué servicio saque primero y de cuánto dependa de él. Damos una estimación fiable después de ver su tienda y sus integraciones, no antes.
¿Cuánto cuesta?
El coste principal está en la integración y en operar varios servicios, no en licencias. Por eso recomendamos empezar con una primera pieza acotada.

¿Qué pieza le frena? Por ahí empezamos.

Planificar la hoja de ruta