Separar estado operativo y estado de cliente
La orquestación inmediata y los hechos consultables no necesitan la misma representación.
Diagrama genérico. No reproduce una arquitectura de cliente.
Un journey puede necesitar estado de inmediato, mientras segmentación, gobierno y Decisioning necesitan hechos acotados y fáciles de consultar. Forzar una única representación para ambos crea objetos frágiles.
El estado operativo se optimiza para actuar. El perfil consultable expone solo los hechos duraderos, y los eventos siguen siendo el histórico auditable.
Señales en producción
- Objetos de perfil que crecen con cada journey.
- Atributos imposibles de reconstruir tras un fallo.
- Segmentos que dependen de campos operativos.
Arquitectura recomendada
Clasificar cada estado por latencia, durabilidad, consumidor y capacidad de reconstrucción antes de elegir almacén.
Mantener el evento como evidencia y subir al perfil solo lo que la operación necesita consultar.
Cuándo no aplicarlo
- No duplicar un hecho estable ya disponible con la latencia necesaria.
- No crear un atributo de perfil sin consumidor concreto.
Pruébalo en un simulador
Escenarios interactivos donde este patrón se ve fallar y se ve resolverse.