Composable Commerce: guía de implementación para ecommerce en México

Hace tres años, el término "composable commerce" apareció en los decks de todos los integradores tecnológicos y se coló en los presupuestos de casi cualquier proyecto de ecommerce relevante en México. La promesa era clara: descomponer la plataforma monolítica en piezas intercambiables, conectar los mejores componentes del mercado y construir exactamente la experiencia que el negocio necesita, sin las restricciones del stack cerrado. Los proyectos arrancaron con entusiasmo. Algunos terminaron en exactamente lo que prometían. Muchos otros se convirtieron en proyectos de 18 meses que todavía no están en producción.

La brecha entre el marketing de composable commerce y la realidad de su implementación en empresas mexicanas es el centro de esta guía. En WolfSellers hemos participado en proyectos de arquitectura desacoplada con clientes de retail, distribución B2B y servicios financieros, y lo que aprendimos en cada uno es que la tecnología no es la parte difícil: la parte difícil es saber cuándo tiene sentido, cuándo no, y cómo ejecutarlo sin que se convierta en un proyecto de infraestructura que paraliza al negocio.

Esta guía está dirigida a CTOs, directores de ecommerce y VPs de tecnología que están evaluando si composable commerce es el camino correcto para su organización, o que ya tomaron la decisión y quieren entender cómo se ve una implementación profesional.

Qué es Composable Commerce

Composable commerce es un enfoque arquitectónico para construir plataformas de ecommerce a partir de servicios independientes, especializados y conectados por APIs, en lugar de una plataforma monolítica que maneja todo dentro de un mismo sistema. El objetivo es que cada capa de la plataforma —catálogo, carrito, checkout, pagos, búsqueda, contenido, personalización— sea reemplazable de forma independiente sin afectar las demás.

El marco conceptual más usado para describir composable commerce es la arquitectura MACH, un acrónimo definido por el MACH Alliance que establece cuatro principios técnicos:

• Microservices (Microservicios): la funcionalidad de la plataforma se distribuye en servicios pequeños y autónomos que se despliegan y escalan de forma independiente. El servicio de catálogo no comparte base de datos ni proceso con el servicio de pagos.
• API-first: cada servicio expone su funcionalidad exclusivamente a través de APIs (típicamente REST o GraphQL). No hay acoplamiento directo entre componentes: todo se comunica por contratos de API.
• Cloud-native: los servicios están diseñados para operar en infraestructura cloud elástica, con escalado automático, resiliencia ante fallos y despliegue continuo. No son aplicaciones heredadas que se "suben a la nube", sino servicios construidos para ese entorno.
• Headless: el frontend (la tienda visible para el consumidor) está completamente desacoplado del backend. El backend provee datos e inteligencia por API; el frontend los consume y los renderiza con total libertad tecnológica —Next.js, Nuxt, React Native, una app nativa, un quiosco físico o cualquier canal que consuma HTTP.

La diferencia con "headless" a secas es de escala y compromiso: headless es una decisión de presentación (separo el frontend del backend), mientras que composable commerce es una decisión de arquitectura completa (separo cada función del negocio en un servicio especializado).

Por qué surgió composable commerce

Las plataformas monolíticas clásicas —incluyendo las versiones más antiguas de Adobe Commerce (antes Magento) en configuraciones on-premise sin extensión de APIs— tienen un problema bien documentado: cuando quieres cambiar el motor de búsqueda, tienes que negociar con el núcleo del monolito. Cuando quieres integrar un nuevo sistema de pagos, dependes del roadmap del vendor. Cuando el Black Friday duplica el tráfico, escalas toda la aplicación aunque el cuello de botella sea solo el checkout.

Gartner declaró en 2021 que "las empresas que adopten arquitecturas componibles superarán a sus competidores en velocidad de implementación de nuevas funcionalidades en un 80%" para 2023. Esa proyección impulsó una adopción masiva, pero también creó expectativas desproporcionadas en contextos organizacionales que no estaban listos para lo que esa arquitectura implica en términos de madurez técnica y operativa.

Monolítico vs. Headless vs. Composable: cuándo aplica cada uno

Antes de decidir la arquitectura, es útil entender el espectro completo de opciones. Las tres no son etapas de evolución obligatoria: son enfoques distintos con perfiles de costo, velocidad y flexibilidad también distintos.

Dimensión	Monolítico	Headless	Composable / MACH
Descripción	Frontend y backend integrados en una sola plataforma (ej. Adobe Commerce con tema Luma o Hyva)	Backend separado del frontend; la API alimenta uno o varios frontends	Cada función del negocio en un servicio independiente; frontend desacoplado
Tiempo a mercado inicial	Rápido (6-12 semanas para un MVP funcional)	Medio (12-20 semanas — requiere construir el frontend)	Lento (6-18 meses para la primera versión estable en producción)
Costo de operación	Bajo-medio (un equipo fullstack puede operar)	Medio (requiere equipo frontend especializado)	Alto (múltiples servicios = múltiples contratos, integraciones, puntos de fallo)
Flexibilidad de frontend	Limitada (templates del vendor)	Alta (cualquier tecnología frontend)	Total (cada canal es un frontend independiente)
Escalabilidad selectiva	Escala todo o nada	Escala frontend y backend por separado	Escala cada microservicio de forma independiente
Integración de mejores herramientas	Difícil (depende del roadmap del vendor)	Parcial (el backend sigue siendo la plataforma base)	Alta (cada función puede ser el mejor servicio del mercado)
Complejidad operativa	Baja	Media	Alta (orquestación, observabilidad distribuida, gestión de múltiples vendors)
Perfil de empresa ideal	PYME o empresa mediana con catálogo estable, un canal de venta principal	Empresa con múltiples canales (web + app + B2B portal), equipo técnico propio	Enterprise con tráfico alto, múltiples regiones o marcas, equipo de ingeniería de producto dedicado
Ejemplo de uso típico	Tienda D2C con 500-5,000 SKUs, un solo mercado, equipo de 2-4 personas en tecnología	Marca con ecommerce.mx + app móvil + portal de distribuidores, equipo de 6-10 personas	Retailer omnicanal con 50k+ SKUs, 3+ países, integraciones con ERP, WMS, OMS, y POS en tiempo real

Esta tabla es deliberadamente directa porque el mercado mexicano tiene una tendencia a sobredimensionar la arquitectura respecto a las capacidades del equipo que la tiene que operar. Un retailer de moda con 2,000 SKUs y un equipo de dos personas en tecnología no necesita composable commerce: necesita una plataforma que funcione de manera confiable y un equipo que la pueda mantener sin contratar cuatro agencias especializadas.

Cuándo sí tiene sentido adoptar composable commerce

La adopción de composable commerce tiene sentido cuando se cumplen condiciones específicas de negocio, tecnología y organización. No es una decisión de tecnología pura: es una decisión de capacidad organizacional.

1. Múltiples canales con experiencias diferenciadas

Si tu empresa opera simultáneamente una tienda web, una aplicación móvil, un portal B2B para distribuidores y puntos de venta físicos con pantallas interactivas, un monolito o incluso una arquitectura headless simple empieza a crujir. Composable commerce permite que cada canal consuma los mismos servicios de backend (catálogo, inventario, precios, carrito) mientras construye su experiencia de presentación de forma completamente independiente.

2. Volumen de transacciones con picos pronunciados

Empresas con tráfico predeciblemente variable —retailers con temporadas de Hot Sale, Buen Fin, navidad o eventos de ventas flash— se benefician de la escalabilidad selectiva de los microservicios. Cuando llega el pico, escalan el servicio de checkout y el motor de búsqueda, no toda la plataforma. Según Forrester Research, el costo de infraestructura en arquitecturas composable es entre un 20 y un 40% más eficiente en escenarios de tráfico variable comparado con escalar una aplicación monolítica completa.

3. Integración compleja con sistemas empresariales

Organizaciones con un ERP consolidado (SAP, Oracle), un WMS propio para gestión de almacén, un OMS para la lógica de fulfillment y un sistema de precios específico para canales B2B encuentran en composable commerce un modelo donde cada integración tiene su capa de responsabilidad clara. En un monolito, estas integraciones terminan siendo parches sobre el código del vendor; en composable, son contratos de API entre servicios.

4. Expansión geográfica o multimarca

Empresas que operan en México y quieren escalar a Colombia, Chile o España —o grupos empresariales con múltiples marcas en el mismo portafolio— se benefician de la arquitectura componible porque pueden compartir servicios de backend (catálogo, inventario consolidado) mientras mantienen frontends y experiencias de marca completamente separados para cada mercado o marca.

5. Equipo técnico interno con capacidad de ingeniería de producto

Este es el criterio más frecuentemente ignorado. Composable commerce funciona cuando la empresa tiene —o está dispuesta a construir— un equipo de ingeniería de producto interno que sea dueño de la arquitectura. Si toda la tecnología es tercerizada y el equipo interno es solo gestión de proyectos, la complejidad operativa de múltiples microservicios, múltiples vendors de SaaS y múltiples integraciones activas crea una deuda de gestión que supera el beneficio técnico.

Cuándo composable commerce no tiene sentido (anti-hype)

Una de las conversaciones más frecuentes que tenemos en WolfSellers en las primeras semanas de un engagement es explicarle a un cliente por qué composable commerce no es la respuesta correcta para su problema actual. Esto no nos hace populares en las demos de arquitectura, pero sí evita proyectos de 18 meses que terminan en frustración.

La plataforma actual funciona y el problema es operativo

Si tu Adobe Commerce (antes Magento) actual tiene bugs, performance deficiente o conversión baja, el problema probablemente no es la arquitectura: es la calidad de la implementación. Reescribir toda la plataforma en microservicios no va a resolver bugs de código ni un tema mal construido. La inversión en optimizar lo existente —PWA Studio sobre la plataforma actual, Live Search de Adobe, optimización de base de datos y cache— suele generar más ROI en 6 meses que una migración completa.

El equipo técnico no puede operar lo que se construye

Hemos visto proyectos en México donde la empresa construyó una arquitectura composable impecable con 8 servicios independientes, y a los 6 meses del go-live ningún desarrollador interno podía hacer un deploy porque los pipelines de CI/CD eran demasiado complejos para el equipo que quedó después de que la agencia terminó el proyecto. La arquitectura más elegante que no se puede operar es peor que un monolito que funciona.

El catálogo y los canales son estables

Si vendes 1,500 SKUs, tienes un solo canal (web), y no planeas abrir app ni B2B portal en los próximos dos años, composable commerce es sobre-ingeniería. La inversión en arquitectura no se justifica con el volumen y la complejidad actuales.

El presupuesto no contempla el costo total de propiedad

Composable commerce no solo implica el costo de desarrollo inicial: implica licencias de múltiples servicios SaaS especializados (motor de búsqueda, sistema de gestión de contenido headless, OMS, PIM), el costo de mantenimiento de integraciones entre ellos, y el equipo que gestiona esa complejidad de forma continua. IDC estima que el costo total de propiedad de una arquitectura composable enterprise es entre 1.5 y 2.5 veces el de una plataforma monolítica bien mantenida en el primer año, con la diferencia reduciéndose en años 2-3 cuando la flexibilidad empieza a generar retornos medibles.

El timeline de negocio no admite el tiempo de implementación

Si necesitas lanzar en 90 días porque tienes un contrato con un cliente o una fecha de temporada crítica, composable commerce no es compatible con ese timeline. Un MVP composable bien hecho requiere mínimo 4-6 meses para las primeras funciones en producción con las integraciones mínimas. Intentar comprimirlo más genera deuda técnica desde el día uno.

Cómo WolfSellers implementa composable commerce con Adobe Commerce

En WolfSellers adoptamos un enfoque que llamamos "composable progresivo": partimos de Adobe Commerce como plataforma central —con todo su ecosistema de APIs, módulos de negocio maduros y capacidades enterprise ya construidas— y desacoplamos capas selectivamente en función de las necesidades reales de negocio, no de un ideal arquitectónico abstracto.

Esto es diferente a lo que muchos integradores proponen, que consiste en construir composable desde cero. Nuestra posición es que Adobe Commerce (antes Magento), en su versión moderna con las APIs de Adobe Commerce extensibility framework, ya es una plataforma API-first que puede funcionar como el núcleo de una arquitectura composable sin necesidad de reemplazarla.

La capa de frontend desacoplado

El primer paso habitual en nuestra implementación es desacoplar el frontend de la plataforma. Adobe Commerce expone un API de catálogo, carrito, checkout y cuenta de cliente completamente documentado a través de GraphQL. Sobre ese API construimos el storefront con PWA Studio —el framework oficial de Adobe para storefronts progresivos basados en React— o, dependiendo del perfil de tráfico y los requerimientos de SEO, con un storefront Next.js personalizado que consume los mismos endpoints.

El resultado es un frontend que:

• Carga en menos de 2 segundos en 3G (LCP < 2.5s medido con Lighthouse), crítico para el mercado móvil mexicano donde el 68% del tráfico de ecommerce proviene de dispositivos móviles (AMVO, Reporte de ecommerce en México 2025).
• Puede desplegarse en un CDN edge completamente separado de la plataforma de commerce, eliminando la correlación entre actualizaciones de backend y disponibilidad del storefront.
• Permite iteraciones de frontend (A/B tests, cambios de UX, nuevas landing pages) sin tocar el núcleo de la plataforma.

Integración con Adobe Experience Manager para contenido

Para clientes con necesidades editoriales intensas —marcas de moda, retailers con campañas estacionales frecuentes, empresas con múltiples micrositios de campaña— integramos Adobe Experience Manager (AEM) como el CMS headless que alimenta el contenido de marketing. La separación es clara: Adobe Commerce gestiona el catálogo, los precios, el inventario y la lógica de transacción; AEM gestiona las páginas de campaña, el contenido editorial, los banners y las experiencias de navegación enriquecida.

La integración entre AEM y Adobe Commerce sucede en el frontend: el storefront consume ambas fuentes de datos —las APIs de catálogo de Commerce y las APIs de contenido de AEM— y las compone en la experiencia final del usuario. Esto permite que el equipo de marketing publique campañas sin involucrar al equipo de desarrollo, mientras el equipo de catálogo actualiza precios y stock de forma independiente.

Adobe Live Search como motor de búsqueda desacoplado

El motor de búsqueda es uno de los componentes que más impacto tiene en la conversión y que más sufre en las arquitecturas monolíticas clásicas. En WolfSellers reemplazamos el motor de búsqueda nativo de Adobe Commerce por Adobe Live Search, un servicio SaaS que usa inteligencia artificial para clasificar resultados por comportamiento de los usuarios, merchandising rules configurables por el equipo de negocio, y facets dinámicos que se adaptan al contexto de cada búsqueda.

Live Search se conecta a la plataforma via API y expone sus propios endpoints que el storefront consume directamente. En implementaciones donde lo hemos desplegado, el impacto en métricas de búsqueda ha sido consistente: tasa de búsquedas sin resultado reducida entre un 30 y un 50%, y una mejora en conversión desde la búsqueda de entre el 15 y el 25% en los primeros 90 días.

Servicios externos especializados por función

Dependiendo de las necesidades de cada cliente, el stack composable puede incluir:

• OMS (Order Management System): cuando la lógica de fulfillment es compleja —múltiples almacenes, envío desde tienda, dropshipping desde proveedores— integramos un OMS especializado conectado a Adobe Commerce por API.
• PIM (Product Information Manager): para catálogos de más de 20,000 SKUs con atributos complejos, integraciones con proveedores y necesidades de publicación multicanal.
• Motor de pagos y antifraude: integraciones nativas con los principales procesadores de México (Conekta, OpenPay, OXXO Pay, PayPal, Mercado Pago) a través de la capa de APIs de Commerce, con reglas de antifraude configuradas por perfil de cliente.
• CDP (Customer Data Platform): Adobe Real-Time CDP como la capa unificada que consolida datos de comportamiento del storefront, datos transaccionales de Commerce y datos de campañas en perfiles de cliente unificados, alimentando la personalización en tiempo real.

Observabilidad y operaciones

Una implementación composable profesional requiere observabilidad distribuida: la capacidad de ver, en un solo panel, qué está pasando en cada servicio y cómo se correlacionan los errores entre ellos. En nuestras implementaciones establecemos desde el inicio un stack de observabilidad que incluye logging centralizado, tracing distribuido entre servicios y alertas configuradas para las métricas de negocio críticas —tasa de error en checkout, latencia del carrito, disponibilidad del motor de búsqueda— no solo métricas de infraestructura.

Esta capa suele ser la más subestimada en los proyectos de composable commerce, y es la que marca la diferencia entre un sistema que se opera proactivamente y uno que solo se repara cuando los clientes reportan problemas.

El proceso de implementación en fases

En WolfSellers seguimos un proceso estructurado en cuatro fases para implementaciones composable. La progresión es deliberada: cada fase entrega valor de negocio antes de avanzar a la siguiente, lo que nos permite validar hipótesis y ajustar la arquitectura con datos reales en lugar de supuestos.

Fase 1: Discovery y arquitectura (semanas 1-6)

El discovery no es una reunión de kickoff: es un proceso de análisis estructurado que produce los insumos para tomar decisiones arquitectónicas con evidencia.

1. Inventario de la plataforma actual: qué módulos están en uso, qué integraciones existen, qué deuda técnica hay que gestionar en la transición.
2. Mapeo de flujos de negocio críticos: los 5-8 flujos que generan el 80% de las transacciones. Son los que no pueden fallar en el go-live.
3. Análisis de equipo y capacidades: quién va a operar esto después de que el proyecto termina, qué gaps hay, qué necesita ser upskilled o contratado.
4. Selección del stack: qué servicios especializados entran en el scope inicial vs. qué queda para fases posteriores.
5. Diseño de la arquitectura: diagramas de componentes, contratos de API, modelo de datos, estrategia de sincronización entre servicios.
6. Plan de migración de datos: cómo se migra el catálogo, clientes, órdenes históricas y configuraciones sin interrumpir la operación.

El entregable de esta fase es un Architecture Decision Record (ADR) que documenta cada decisión técnica con su contexto, alternativas consideradas y consecuencias esperadas. Este documento es el contrato técnico que guía el resto del proyecto.

Fase 2: MVP en staging (semanas 7-18)

Con la arquitectura validada, construimos el MVP que cubre los flujos de negocio críticos identificados en el discovery. El criterio de done para el MVP no es "está todo implementado" sino "los flujos críticos funcionan con la misma confiabilidad que la plataforma actual".

Esto incluye:

• Storefront conectado a las APIs de Commerce con flujo completo de compra (catálogo → búsqueda → PDP → carrito → checkout → confirmación).
• Integraciones activas con los sistemas externos que participan en el flujo de compra (ERP para inventario en tiempo real, procesador de pagos, sistema de envíos).
• Observabilidad instalada y alertas activas.
• Tests de carga que simulan el pico de tráfico esperado (Buen Fin, Hot Sale o el evento de mayor demanda del cliente).

Fase 3: Go-live y estabilización (semanas 19-24)

El go-live de una arquitectura composable no es un corte instantáneo: es una transición controlada. Nuestra metodología usa feature flags para activar el nuevo storefront para un porcentaje creciente del tráfico, comenzando con el 5-10% de los usuarios, monitorizando métricas de negocio y técnicas en tiempo real, y escalando solo cuando los números confirman paridad o mejora respecto a la plataforma anterior.

Durante las primeras semanas en producción, el equipo de WolfSellers opera en modo de guardia activa: hay disponibilidad 24/7 para responder incidentes y los SLAs de respuesta son de 15 minutos para problemas críticos (checkout caído, error en procesamiento de pagos).

Fase 4: Escalar y optimizar (mes 7 en adelante)

Una vez estabilizado el MVP, el trabajo cambia de naturaleza: de construcción a optimización y expansión. En esta fase:

• Se agregan los componentes que quedaron fuera del scope inicial (nuevos canales, integraciones adicionales, funciones de merchandising avanzado).
• Se establecen los ciclos de mejora continua: pruebas A/B en el storefront, ajuste de reglas de merchandising en Live Search, optimización de la personalización en Adobe Target.
• Se transfiere gradualmente la operación al equipo interno del cliente, con documentación, runbooks y capacitación.
• Se revisan los SLAs y se ajustan los umbrales de alertas según el comportamiento real en producción.

Checklist de madurez: ¿está tu empresa lista para composable commerce?

Usa este checklist antes de iniciar un proyecto de composable commerce. Cada ítem marcado con "Requerido" es un prerrequisito. Si alguno de esos no se cumple, la conversación correcta es cómo llegamos ahí antes de iniciar la arquitectura, no cómo saltamos ese paso.

Madurez técnica

• [Requerido] La empresa tiene al menos 2 ingenieros de software full-time que serán dueños de la plataforma después del proyecto.
• [Requerido] Existe un proceso de CI/CD funcional para al menos una parte de la plataforma actual.
• [Requerido] Se tienen definidos SLAs de disponibilidad y existen métricas para medirlos.
• El equipo tiene experiencia con APIs REST o GraphQL (consumo e integración, no necesariamente desarrollo de APIs).
• Hay familiaridad con herramientas de observabilidad (logs, métricas, trazas).

Madurez de negocio

• [Requerido] Los flujos de negocio críticos (compra, carrito, pagos) están documentados y hay criterios claros de aceptación.
• [Requerido] El presupuesto contempla el costo operativo recurrente (licencias SaaS + equipo de operación), no solo el desarrollo inicial.
• Hay un dueño de producto (Product Owner) dedicado con autoridad para priorizar funcionalidades.
• Los stakeholders de negocio pueden participar en reviews cada 2-3 semanas durante la implementación.

Madurez de datos

• El catálogo tiene un identificador único de producto consistente a través de todos los sistemas (ERP, Commerce, etc.).
• Los datos de clientes tienen una definición de identidad acordada entre los equipos de marketing y tecnología.
• Existe una política de gestión de datos personales alineada con la Ley Federal de Protección de Datos en México.

Señales de alerta

• Si el proyecto tiene fecha de go-live en menos de 4 meses, el scope debe reducirse a lo estrictamente necesario.
• Si el equipo de tecnología actual no puede nombrar los 5 flujos de negocio críticos sin consultar documentación, el discovery necesita más tiempo.
• Si el presupuesto total está por debajo de lo que requiere el costo total de propiedad en 12 meses, la conversación correcta es ajustar el alcance o la arquitectura.

Preguntas frecuentes de CTOs y VPs de ecommerce

¿Composable commerce con Adobe Commerce implica dejar de usar la plataforma?

No. Nuestra implementación usa Adobe Commerce como el núcleo transaccional de la arquitectura: gestión de catálogo, precios, inventario, órdenes y cuentas de cliente. Lo que desacoplamos es el frontend (mediante PWA Studio o un storefront Next.js) y los servicios especializados que el negocio requiere (búsqueda, contenido, pagos avanzados). Adobe Commerce tiene un API GraphQL maduro y un framework de extensibilidad que lo hace compatible con arquitecturas composable sin necesidad de reemplazarlo.

¿Cuánto tiempo tarda un proyecto composable típico?

Para una implementación con storefront desacoplado, Adobe Live Search y las integraciones con ERP y procesadores de pago principales, el rango realista es de 16 a 24 semanas hasta el primer go-live en producción con los flujos críticos funcionando. Proyectos con requisitos adicionales —múltiples marcas, integración con AEM, OMS propio— pueden extenderse a 9-12 meses para la versión completa. Los proyectos que se prometen en menos de 12 semanas para una implementación composable completa casi invariablemente generan deuda técnica que se paga en los 12 meses siguientes.

¿Qué pasa con el SEO durante la transición a headless/composable?

El riesgo de SEO en una migración a headless es real pero gestionable. Los puntos críticos son: asegurar que el nuevo storefront renderiza correctamente para Googlebot (server-side rendering o static generation, no solo client-side rendering), mantener todas las URLs canónicas y el mapeo de redirects de las URLs anteriores, y validar que las meta tags, datos estructurados y hreflang se generan correctamente en el nuevo stack. En nuestra metodología incluimos una auditoría SEO técnica pre y post migración, y el go-live no se aprueba hasta que el rastreo del nuevo storefront por herramientas como Google Search Console muestra paridad con la plataforma anterior.

¿Cómo manejamos la consistencia de datos entre microservicios?

La consistencia eventual es uno de los trade-offs reales de la arquitectura composable. En un monolito, todo está en la misma base de datos y las transacciones son atómicas. En microservicios, cuando el inventario se actualiza en el ERP, esa actualización llega al catálogo de Commerce y al storefront con cierta latencia. Diseñamos esta latencia explícitamente: para datos críticos (stock en tiempo real durante el checkout) usamos APIs síncronas; para datos menos críticos (precios de catálogo, descripciones de producto) usamos sincronización por eventos con una latencia de segundos o minutos que es completamente aceptable para el caso de uso.

¿Qué pasa si un microservicio falla? ¿Cae toda la tienda?

No, si la arquitectura está diseñada con degradación elegante. En nuestra implementación, el storefront está construido para manejar la no disponibilidad de servicios externos de forma controlada: si Live Search falla, el checkout sigue funcionando con la búsqueda básica de Commerce; si el servicio de recomendaciones no responde, la página de producto carga sin la sección de recomendaciones en lugar de retornar un error. Los circuit breakers y los fallbacks son parte del diseño desde el inicio, no parches que se agregan después del primer incidente en producción.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo:

• Composable Commerce
• Adobe Commerce
• PWA Studio