{"id":37042,"date":"2026-06-18T09:09:16","date_gmt":"2026-06-18T12:09:16","guid":{"rendered":"https:\/\/building.nu.com\/?p=37042"},"modified":"2026-07-01T11:44:07","modified_gmt":"2026-07-01T14:44:07","slug":"feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion","status":"publish","type":"post","link":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/","title":{"rendered":"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n"},"content":{"rendered":"\n

Escrito por: Felipe Almeida<\/a>, con contribuciones de Luiz Felix<\/a><\/p>\n\n\n\n


Esta es la <\/em>parte 2<\/em><\/strong> de una serie de 3 partes sobre Feature Stores para ML en tiempo real. En la <\/em>parte 1<\/em><\/strong> hablamos sobre la Introducci\u00f3n y tambi\u00e9n sobre los Pros y Contras. En la <\/em>parte 3<\/em><\/strong> concluimos con configuraciones de arquitectura del mundo real de extremo a extremo de Nubank.<\/em><\/p>\n\n\n\n

Un repaso r\u00e1pido<\/strong><\/h2>\n\n\n\n

En la parte 1<\/a>, exploramos qu\u00e9 son los feature stores y el papel que desempe\u00f1an en los sistemas de machine learning en tiempo real. Analizamos c\u00f3mo ayudan a mitigar problemas cruciales como el training-serving skew y por qu\u00e9, a pesar de los costos de adopci\u00f3n, son una inversi\u00f3n valiosa para las organizaciones que operan ML a escala.<\/p>\n\n\n\n

En los \u00faltimos a\u00f1os, hemos utilizado feature stores en una amplia gama de aplicaciones de ML en tiempo real en Nubank, incluyendo an\u00e1lisis de cr\u00e9dito, detecci\u00f3n de fraudes y atenci\u00f3n al cliente. En el camino, hemos visto surgir patrones recurrentes, nos hemos enfrentado a desaf\u00edos inesperados y hemos reunido lecciones pr\u00e1cticas que nos ayudaron a evitar errores comunes mientras maximiz\u00e1bamos el valor entregado por la plataforma.<\/p>\n\n\n\n

En este art\u00edculo<\/strong>, cubriremos algunas que consideramos especialmente importantes.<\/p>\n\n\n\n

Lecci\u00f3n: Construir vs comprar es un espectro <\/strong><\/h2>\n\n\n\n

Es com\u00fan referirse al dilema \u201cconstruir vs comprar\u201d al hablar de plataformas complejas como los feature stores. Algunas organizaciones pueden querer construir todo internamente, mientras que otras pueden querer trasladar parte de la complejidad a feature stores m\u00e1s \u201ccompletos\u201d como Chalk<\/a> o Feast<\/a>.<\/p>\n\n\n\n

En nuestra opini\u00f3n, no tienes que elegir<\/em> entre construir todo<\/em> o comprar todo<\/em>. En su lugar, puedes tener un feature store h\u00edbrido<\/em>: construyes algunas partes, usas herramientas open-source en otras y delegas a proveedores de servicios externos cuando sea necesario. Esto es similar al enfoque que seguimos actualmente en Nubank<\/a>.<\/p>\n\n\n\n

Construir vs comprar no es una elecci\u00f3n binaria: puedes optar por \u201ccomprar\u201d algunos componentes y construir otros t\u00fa mismo.<\/em><\/p>\n\n\n\n

Figura 1 a continuaci\u00f3n muestra una vista de alto nivel de un feature store en tiempo real y algunos de los componentes que pueden existir en cada capa. Cada uno de estos componentes puede ser \u201cconstruido\u201d o \u201ccomprado\u201d.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Figura 1: <\/strong>Un feature store en tiempo real tiene muchos componentes y muchos de ellos podr\u00edan, en teor\u00eda, construirse internamente o comprarse como un producto \u201cllave en mano\u201d. Curiosamente, muchos proyectos open-source han dado origen a empresas que ofrecen versiones gestionadas de los mismos (p. ej. Kafka\/Confluent, Spark\/Databricks, Cassandra\/Datastax).<\/p>\n\n\n\n

En Nubank, usamos herramientas open-source como Kubernetes, Kafka, Pinot, Spark y Flink para las partes centrales de la arquitectura, donde nuestros casos de uso no se alejan demasiado<\/em> de aquello para lo que est\u00e1n dise\u00f1adas las herramientas. Tambi\u00e9n usamos servicios totalmente gestionados de nuestros proveedores de nube, mientras que otros componentes (como nuestra infraestructura de monitoreo) se construyen internamente. <\/p>\n\n\n\n

La clave para decidir qu\u00e9 partes se \u201cconstruyen\u201d vs se \u201ccompran\u201d tiene que ver con el nivel de control que tienes y con d\u00f3nde los patrones de flujo de trabajo de tu organizaci\u00f3n son demasiado diferentes de los casos de uso predeterminados para los que est\u00e1n dise\u00f1adas las herramientas: en estos casos, puede que no tengas otra opci\u00f3n que construir.<\/p>\n\n\n\n

Lecci\u00f3n: Los feature stores son <\/strong>productos <\/em><\/strong>y deben gestionarse como tales <\/strong><\/h2>\n\n\n\n

Adem\u00e1s de ser sistemas<\/em>, los feature stores tambi\u00e9n son productos<\/em>. Y los productos son entidades vivas que necesitan ser gestionadas<\/em>, idealmente por un Product Manager (PM) dedicado. Todo lo relacionado con la gesti\u00f3n de productos internos aplica aqu\u00ed. <\/p>\n\n\n\n

Muchas de las pr\u00e1cticas com\u00fanmente asociadas con la gesti\u00f3n de productos internos aplican directamente a los feature stores, como:<\/p>\n\n\n\n

    \n
  • Roadmap y priorizaci\u00f3n de tareas:<\/strong> \u00bfQu\u00e9 tareas y mejoras deben construirse primero? \u00bfQu\u00e9 solicitudes quedan fuera del alcance de la plataforma y por qu\u00e9?<\/li>\n\n\n\n
  • Canales de soporte:<\/strong> \u00bfC\u00f3mo obtendr\u00e1n ayuda los usuarios cuando encuentren problemas o tengan preguntas? \u00bfHabr\u00e1 una rotaci\u00f3n de ingenieros para brindar soporte? \u00bfC\u00f3mo har\u00e1 el equipo para medir el tiempo que toma responder preguntas?<\/li>\n\n\n\n
  • Entrevistas\/encuestas a usuarios:<\/strong> \u00bfC\u00f3mo evaluar\u00e1 el equipo de FS qu\u00e9 tan satisfechos est\u00e1n los usuarios con el producto? <\/li>\n\n\n\n
  • Gesti\u00f3n de stakeholders:<\/strong> \u00bfC\u00f3mo se mantendr\u00e1n informados los stakeholders clave sobre las mejoras del producto? \u00bfQui\u00e9n deber\u00eda participar en la definici\u00f3n del roadmap para que se atiendan las prioridades de la empresa?<\/li>\n<\/ul>\n\n\n\n

    Ten en cuenta que los feature stores se diferencian de otros productos internos en que naturalmente abarcan m\u00faltiples disciplinas. Resolver un problema de training-serving skew, por ejemplo, a menudo requiere colaboraci\u00f3n entre ingenieros de software, ingenieros de datos, cient\u00edficos de datos y especialistas de dominio. Como resultado, operar un feature store con \u00e9xito implica coordinar la experiencia de varias \u00e1reas de la organizaci\u00f3n.<\/p>\n\n\n\n

    Lecci\u00f3n: Define una convenci\u00f3n de nomenclatura para las features<\/strong><\/h2>\n\n\n\n

    Establece una convenci\u00f3n de nomenclatura para las features en el feature store. Las convenciones de nomenclatura tienen muy pocas desventajas (especialmente cuando son lo suficientemente ligeras como para acomodar muchos casos de uso).<\/p>\n\n\n\n

    Usa una convenci\u00f3n de nomenclatura para las features: ayuda a humanos y herramientas de IA a navegar por el c\u00f3digo.<\/em><\/p>\n\n\n\n

    Las convenciones de nomenclatura tienen varias ventajas (al igual que la estandarizaci\u00f3n<\/em> en general):<\/p>\n\n\n\n

      \n
    • Menor probabilidad de error humano:<\/strong> Los nombres estandarizados hacen que tareas como las revisiones de c\u00f3digo, copiar y pegar y las ediciones masivas sean m\u00e1s seguras y f\u00e1ciles.<\/li>\n\n\n\n
    • Menor carga cognitiva:<\/strong> Los usuarios pueden inferir qu\u00e9 representa una feature sin necesitar documentaci\u00f3n.<\/li>\n\n\n\n
    • Mayor descubribilidad de features:<\/strong> Los usuarios se exponen naturalmente a otros elementos del mismo grupo al explorar features.<\/li>\n\n\n\n
    • Monitoreo y depuraci\u00f3n m\u00e1s simples:<\/strong> La mayor\u00eda de los problemas de features (p. ej. drift, skew) afectan a grupos enteros de features, lo que facilita identificar los problemas cuando esas relaciones son visibles.<\/li>\n\n\n\n
    • Refactorizaci\u00f3n y organizaci\u00f3n m\u00e1s f\u00e1ciles: <\/strong>Los nombres de los grupos de features sirven como namespaces naturales que pueden reutilizarse en carpetas, dashboards y otros recursos de monitoreo.<\/li>\n<\/ul>\n\n\n\n

      En realidad no importa qu\u00e9<\/em> convenci\u00f3n de nomenclatura elijas, siempre que sea vers\u00e1til y permita cierta personalizaci\u00f3n. Si las reglas se vuelven demasiado restrictivas, los usuarios tendr\u00e1n que doblar<\/em> y hackear <\/em>la convenci\u00f3n de nomenclatura hasta que ya no sirva para nada.<\/p>\n\n\n\n

      Algunos ejemplos:<\/p>\n\n\n\n

        \n
      • customer_cc_transactions_24h_count<\/li>\n\n\n\n
      • customer_app_behavior_2h_logins<\/li>\n\n\n\n
      • savings_account_5d_balance_daily_avg<\/li>\n\n\n\n
      • savings_account__current_balance (el bloque TIME_FRAME se omite, ya que es el saldo de la cuenta de ahorros en un momento dado).<\/li>\n<\/ul>\n\n\n\n

        Algunas recomendaciones adicionales:<\/p>\n\n\n\n

          \n
        • Evita usar m para representar meses, ya que puede confundirse con minutos<\/em>. Si una feature cubre los \u00faltimos 2 meses, prefiere 60d.<\/li>\n\n\n\n
        • Usa nombres a prueba de futuro que no dependan de la estructura del equipo, sino de conceptos de negocio. Los nombres de los equipos reflejan la estructura organizacional y cambian con mucha frecuencia, mientras que los conceptos de negocio tienden a permanecer estables a lo largo del tiempo.<\/li>\n<\/ul>\n\n\n\n

          Lecci\u00f3n: Versionar features es dif\u00edcil<\/strong><\/h2>\n\n\n\n

          Supongamos que un equipo necesita una peque\u00f1a variaci\u00f3n de una feature en tiempo real existente en el Feature Store. El equipo de FS no puede simplemente cambiar la implementaci\u00f3n de la feature, ya que eso causar\u00eda training-serving skew para los modelos entrenados con la versi\u00f3n actual de la feature. (Puede que no quieran reentrenar sus modelos con la versi\u00f3n m\u00e1s nueva).<\/p>\n\n\n\n

          Por lo tanto, hay que crear una feature completamente nueva o una nueva versi\u00f3n <\/em>de una feature existente. La mayor\u00eda de los feature stores admiten el versionado<\/em> de features pero, en la pr\u00e1ctica, esto significa que los clientes deben proporcionar la versi\u00f3n<\/em> de la feature que quieren, adem\u00e1s de su nombre.<\/p>\n\n\n\n

          Sin embargo, no es tan f\u00e1cil saber qu\u00e9 cambios se describen mejor como una nueva versi\u00f3n de una feature existente o como una feature completamente nueva por s\u00ed sola. Hay que aplicar criterio para decidir qu\u00e9 acci\u00f3n tomar en cada caso.<\/p>\n\n\n\n

          Por ejemplo: tienes una feature llamada customer_cc_purchases__5d__count. Intuitivamente, es el n\u00famero de compras con tarjeta de cr\u00e9dito realizadas por un cliente dado en los \u00faltimos 5 d\u00edas. Ahora veamos algunos escenarios de lo que puede suceder en una situaci\u00f3n del mundo real, en la Figura 2:<\/p>\n\n\n\n

          \"\"<\/figure>\n\n\n\n

          Figura 2: <\/em><\/strong>Ejemplos de situaciones donde los equipos pueden necesitar crear una nueva versi\u00f3n de una feature existente, crear una diferente por completo (dependiendo de la sem\u00e1ntica del cambio) o, en algunos casos, no hacer nada en absoluto.<\/em><\/p>\n\n\n\n

          El desaf\u00edo es que el versionado puede volverse r\u00e1pidamente dif\u00edcil de gestionar. Es f\u00e1cil terminar con docenas de versiones de una feature, lo que significa un conjunto de features complejo y desordenado (diferentes equipos tienen diferentes calendarios de reentrenamiento y siempre hay modelos que a\u00fan est\u00e1n atados a versiones anteriores de features y no pueden reentrenarse en este momento).<\/p>\n\n\n\n

          Una posible salida de este \u201cinfierno de versionado\u201d es que el equipo del feature store se encargue<\/em> de migrar los modelos que usan versiones antiguas de features para que usen las nuevas. La situaci\u00f3n es similar al trabajo de actualizar aplicaciones para eliminar bibliotecas y dependencias antiguas y sin soporte en favor de versiones m\u00e1s nuevas. <\/p>\n\n\n\n

          Los data contracts <\/strong>tambi\u00e9n pueden usarse para mitigar los problemas de versionado: los productores de features establecen las expectativas y se notifica a los consumidores cuando ocurren cambios de esquema y sem\u00e1nticos.<\/p>\n\n\n\n

          Lecci\u00f3n: Usa una arquitectura de streaming cuando puedas y llamadas directas cuando debas<\/strong><\/h2>\n\n\n\n

          Como se discuti\u00f3 en la Parte 1, hay dos formas principales de recuperar features para la inferencia en tiempo real. La primera se basa en llamadas directas a los sistemas que poseen los datos de origen, mientras que la segunda se basa en una plataforma de streaming intermediaria que recibe y procesa eventos continuamente.<\/p>\n\n\n\n

          Estos enfoques pueden resumirse como:<\/p>\n\n\n\n

          Features de \u201cllamada directa\u201d<\/strong><\/h3>\n\n\n\n

          Las features se recuperan mediante llamadas HTTP a los microservicios que poseen las bases de datos transaccionales \u201cfuente de verdad\u201d. Dependiendo del caso de uso, esto puede incluir m\u00faltiples llamadas y joins.<\/p>\n\n\n\n

          Features basadas en streaming<\/strong><\/h3>\n\n\n\n

          En su lugar, las features se recuperan de un store intermediario: normalmente una base de datos de corto plazo que escucha eventos de un bus de eventos como Kafka.<\/p>\n\n\n\n

          Como regla general, recomendamos favorecer las features basadas en streaming siempre que sea posible. <\/strong>Hay varias razones para esto: <\/strong><\/p>\n\n\n\n

            \n
          • Mejor escalabilidad<\/strong>: Las features de streaming escalan mejor, porque la ingesta de datos est\u00e1 desacoplada del consumo de datos. Un aumento en la tasa de consumo de eventos no requiere que los productores tambi\u00e9n escalen.<\/li>\n\n\n\n
          • Mejor aislamiento de fallos y menor radio de impacto en caso de ca\u00eddas:<\/strong> Las arquitecturas as\u00edncronas proporcionan un \u201caislamiento de entornos\u201d natural que reduce los fallos en cascada. Si el productor o el consumidor se cae, no causa un fallo en el otro extremo.<\/li>\n\n\n\n
          • Menor carga en los servicios transaccionales<\/strong>: En una arquitectura de streaming, el feature store no consulta los servicios \u201cfuente\u201d para obtener informaci\u00f3n. Estos servicios normalmente tienen otras responsabilidades adem\u00e1s de proporcionar datos para cargas de trabajo de ML, por lo que no se quiere sobrecargarlos provocando su ca\u00edda, lo que podr\u00eda causar interrupciones de negocio en flujos no relacionados.<\/li>\n<\/ul>\n\n\n\n

            Es cierto que usar features de streaming requiere una \u201cplataforma\u201d de streaming, que es la infraestructura de m\u00e1s bajo nivel que permite a los servicios de origen transmitir eventos a un bus de eventos as\u00edncrono (normalmente Apache Kafka). Esta es una plataforma compleja y costosa en s\u00ed misma, y es un prerrequisito para las features de streaming.<\/p>\n\n\n\n

            Lecci\u00f3n: La recuperaci\u00f3n de features por llamada directa y por streaming tiene diferentes modos de fallo<\/strong><\/h2>\n\n\n\n

            La recuperaci\u00f3n de features fallar\u00e1 de vez en cuando, ya sea usando estrategias de \u201cllamada directa\u201d o basadas en streaming. Algunos modos de fallo son \u201cexpl\u00edcitos\u201d (es decir, excepciones e interrupciones de flujo), mientras que otros son \u201csilenciosos\u201d. Esto ocurre porque simplemente cambian la distribuci\u00f3n de la feature, pero no disparan excepciones expl\u00edcitas. (Los fallos silenciosos son muy peligrosos porque corres el riesgo de tomar malas decisiones durante d\u00edas o semanas antes de que alguien detecte que hay un problema.)<\/p>\n\n\n\n

            Cada estrategia falla de maneras diferentes, y la naturaleza as\u00edncrona de la estrategia de streaming introduce algunos modos de fallo distintos a los que uno podr\u00eda no estar acostumbrado. Debes entender c\u00f3mo falla cada una y cu\u00e1les son las implicaciones para tu negocio. <\/p>\n\n\n\n

              \n
            • Las features de \u201cllamada directa\u201d<\/strong> fallan expl\u00edcitamente si el microservicio propietario no est\u00e1 disponible por cualquier motivo:<\/strong> Esto incluye timeouts, ca\u00eddas del servicio e incluso la sobrecarga del servicio causada por la propia obtenci\u00f3n de la feature.<\/em><\/li>\n\n\n\n
            • Las features de \u201cllamada directa\u201d fallan silenciosamente si se cambia alguna l\u00f3gica en el servicio de origen:<\/strong> Muy a menudo, los ingenieros que poseen los servicios no saben que algunos endpoints se usan para \u201calimentar\u201d modelos en tiempo real. A veces, hacen cambios para soportar alg\u00fan caso de negocio y, sin darse cuenta, cambian la distribuci\u00f3n de los datos solicitados, lo que causa un problema de training-serving skew.<\/li>\n\n\n\n
            • Las features de streaming fallan silenciosamente si los retrasos se vuelven demasiado grandes:<\/strong> Aunque cierto nivel de retraso es esperable en las features de streaming, a veces este retraso alcanza niveles inaceptables debido a una serie de factores estructurales y temporales. Esto significa que el modelo en tiempo real consumir\u00e1 informaci\u00f3n obsoleta, lo que lleva a training-serving skew y a una degradaci\u00f3n del rendimiento.<\/li>\n\n\n\n
            • Las features de streaming fallan silenciosamente si los eventos llegan fuera de orden:<\/strong> Dependiendo del bus de eventos usado para procesar las features ingeridas, algunos eventos pueden llegar fuera de orden, lo que causar\u00e1 training-serving skew y degradaci\u00f3n del rendimiento en los modelos.<\/li>\n\n\n\n
            • Las features de streaming fallan silenciosamente si no hay una paridad estricta entre la ingesta por batch y por streaming:<\/strong> Muy a menudo, los ingenieros hacen cambios en la l\u00f3gica de ingesta por batch pero olvidan replicar los cambios en la l\u00f3gica de ingesta por streaming. En estos casos, los datos de streaming se \u201cdesincronizar\u00e1n\u201d con los datos de batch, lo que causar\u00e1 training-serving skew. Deber\u00eda haber pruebas de integraci\u00f3n para garantizar que todo lo que se ingiere en batch tambi\u00e9n se ingiere en la capa de streaming.<\/li>\n<\/ul>\n\n\n\n

              Lecci\u00f3n: El monitoreo del training-serving skew sigue siendo necesario<\/strong><\/h2>\n\n\n\n

              El training-serving skew se refiere a diferencias no deseadas entre c\u00f3mo se generan las features durante el tiempo de entrenamiento<\/em> y c\u00f3mo se recuperan en el tiempo de inferencia o serving<\/em>. <\/p>\n\n\n\n

              En la parte 1, argumentamos que los feature stores ayudan a mitigar este problema, porque ambos \u201ccaminos\u201d de datos (batch y tiempo real) se definen en un \u00fanico lugar. Esto reduce la posibilidad de que tales desviaciones pasen desapercibidas.<\/p>\n\n\n\n

              Sin embargo, los feature stores no eliminan<\/strong> el problema. Todav\u00eda es necesario monitorear<\/strong> el training-serving skew, ya que todav\u00eda hay muchas formas en que los datos de batch y de tiempo real pueden desincronizarse incluso cuando ambos caminos se definen dentro de la plataforma del feature store. Dos ejemplos: (1) Los servicios upstream pueden cambiar la sem\u00e1ntica de un campo en el camino de tiempo real sin actualizar el equivalente en batch. (2) Puede haber algunos retrasos sistem\u00e1ticos en el bus de eventos, lo que provoca que las features de streaming en tiempo real siempre<\/em> lleguen tarde en comparaci\u00f3n con el instante en que deber\u00edan haber estado disponibles.<\/p>\n\n\n\n

              Pero, \u00bfc\u00f3mo es realmente el monitoreo del training-serving skew en la pr\u00e1ctica?<\/p>\n\n\n\n

              Se puede detectar el training-serving skew generando program\u00e1ticamente la l\u00f3gica de extracci\u00f3n de features del tiempo de entrenamiento (sin el target) para aquellos ejemplos que fueron puntuados en tiempo real en el pasado reciente, y luego compar\u00e1ndolos con los valores reales usados en el tiempo de inferencia (obtenidos de los logs de producci\u00f3n). Se puede ver una representaci\u00f3n visual en la Figura 3 a continuaci\u00f3n:<\/p>\n\n\n\n

              \"\"<\/figure>\n\n\n\n

              Figura 3: <\/em><\/strong>Una posible estrategia para monitorear el training-serving skew es extraer features usando la l\u00f3gica de batch para instancias puntuadas en tiempo real y luego comparar los valores obtenidos en cada \u201ccamino\u201d y ver si coinciden. Esto puede ejecutarse de forma ad-hoc o como un trabajo diario recurrente.<\/em><\/p>\n\n\n\n

              Aqu\u00ed aplica una advertencia importante: Esta estrategia de monitoreo asume que los equipos son capaces de generar program\u00e1ticamente<\/em> conjuntos de datos de entrenamiento para los modelos, que se usar\u00e1n como referencia de comparaci\u00f3n frente a los logs en tiempo real. Esto no solo habilita el monitoreo del training-serving skew, sino que es crucial<\/strong> para garantizar la reproducibilidad.<\/p>\n\n\n\n

              Lecci\u00f3n: Los proyectos piloto son una de las formas m\u00e1s efectivas de impulsar la adopci\u00f3n<\/strong><\/h2>\n\n\n\n

              Al introducir un feature store en una organizaci\u00f3n, puede que no todos los equipos quieran<\/em> usarlo de inmediato, ya que podr\u00edan<\/em> perder algo de autonom\u00eda y control sobre las features, perder poder relativo en la organizaci\u00f3n, tener que despriorizar otros proyectos, etc. Los factores habituales que contribuyen a resistir los esfuerzos de plataformizaci\u00f3n.<\/p>\n\n\n\n

              El mejor argumento para adoptar un feature store es una visi\u00f3n clara de los beneficios. Pero si todav\u00eda hay resistencia de los equipos cliente, los proyectos piloto a cargo del equipo de FS son un buen camino a seguir.<\/em><\/p>\n\n\n\n

              La adopci\u00f3n del feature store debe fomentarse con zanahorias, no con palos (p. ej. mandatos<\/em> de arriba hacia abajo). Al final del d\u00eda, los beneficios de usar un feature store (mayor impacto, m\u00e1s robustez, menor TTM, etc.) deben ser claros para fomentar la adopci\u00f3n. Figura 4 resume varias razones comunes por las que los equipos dudan en adoptar feature stores, junto con posibles estrategias de mitigaci\u00f3n.<\/p>\n\n\n\n

              \"\"<\/figure>\n\n\n\n

              Figura 4: <\/em><\/strong>Hay muchas razones por las que los equipos se resisten a adoptar feature stores. La mayor\u00eda de ellas pueden mitigarse si el equipo del Feature Store comparte parte de la carga de integraci\u00f3n (es decir, proyectos piloto) y si hay documentaci\u00f3n clara y buenos canales de soporte.<\/em><\/p>\n\n\n\n

              En la Figura 4, vemos que una gran estrategia de mitigaci\u00f3n general es que el equipo de FS cree las primeras integraciones para los equipos cliente, como proyectos piloto<\/strong>. <\/p>\n\n\n\n

              Estos proyectos reducen enormemente el costo de adopci\u00f3n (desde el punto de vista de los equipos cliente) y es una estrategia \u00abwin-win\u201d: el equipo cliente obtiene features construidas \u201cgratis\u201d y el equipo de FS tiene un proyecto piloto para someter la plataforma a pruebas de estr\u00e9s y servir como ejemplo del que otros equipos pueden aprender.<\/p>\n\n\n\n

              Conclusi\u00f3n<\/strong><\/h1>\n\n\n\n

              Como afirmamos en la parte 1, los feature stores requieren una inversi\u00f3n significativa en ingenier\u00eda de plataforma, madurez operacional y alineaci\u00f3n organizacional. Pero para las empresas que ejecutan sistemas de ML en tiempo real a escala, esa inversi\u00f3n desbloquea beneficios sustanciales a largo plazo.<\/p>\n\n\n\n

              Nuestra experiencia en Nubank ha demostrado que la adopci\u00f3n exitosa de un feature store no se trata solo de decisiones tecnol\u00f3gicas. Tambi\u00e9n depende del pensamiento de producto, de pr\u00e1cticas operacionales s\u00f3lidas y de una comprensi\u00f3n profunda de c\u00f3mo evolucionan los sistemas de ML del mundo real a lo largo del tiempo.<\/p>\n\n\n\n

              En el camino, algunas lecciones destacan de forma consistente:<\/p>\n\n\n\n

                \n
              • Es posible combinar varios tipos de componentes (open-source, de proveedores, hechos en casa) para adaptar tu configuraci\u00f3n a tus necesidades espec\u00edficas. <\/li>\n\n\n\n
              • Los feature stores son productos y deben gestionarse como tales.<\/li>\n\n\n\n
              • Definir y hacer cumplir<\/em> una convenci\u00f3n de nomenclatura reduce la carga cognitiva y facilita el versionado.<\/li>\n\n\n\n
              • Las features basadas en streaming escalan mejor. Los feature stores tambi\u00e9n deben admitir la llamada directa para casos extremos.<\/li>\n\n\n\n
              • Los flujos de trabajo s\u00edncronos y as\u00edncronos son muy diferentes y fallan de maneras diferentes. Entiende c\u00f3mo falla cada uno y c\u00f3mo afectan a tu negocio.<\/li>\n\n\n\n
              • Usar feature stores mitiga, pero nunca elimina por completo el training-serving skew. El monitoreo sigue siendo necesario.<\/li>\n\n\n\n
              • Los proyectos piloto son una excelente t\u00e1ctica integral para ayudar a demostrar<\/em> el beneficio de las iniciativas de tipo plataforma. Los feature stores no son la excepci\u00f3n.<\/li>\n<\/ul>\n\n\n\n

                Esta es la Parte 2 de nuestra serie sobre Feature Stores para ML en Tiempo Real en Nubank. En la Parte 3, reuniremos estos conceptos y exploraremos arquitecturas del mundo real que usamos en la pr\u00e1ctica.<\/p>\n","protected":false},"excerpt":{"rendered":"

                Tras a\u00f1os operando feature stores en diversos flujos de trabajo, aqu\u00ed est\u00e1n algunas lecciones que moldearon nuestro enfoque.<\/p>\n","protected":false},"author":178110103,"featured_media":37060,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_wpcom_ai_launchpad_first_post":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[2508],"tags":[],"class_list":["post-37042","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-science-machine-learning-es"],"acf":[],"yoast_head":"\nFeature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n - Building Nubank<\/title>\n<meta name=\"description\" content=\"Tras a\u00f1os operando feature stores en diversos flujos de trabajo, aqu\u00ed est\u00e1n algunas lecciones que moldearon nuestro enfoque.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/\" \/>\n<meta property=\"og:locale\" content=\"es_ES\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n - Building Nubank\" \/>\n<meta property=\"og:description\" content=\"Tras a\u00f1os operando feature stores en diversos flujos de trabajo, aqu\u00ed est\u00e1n algunas lecciones que moldearon nuestro enfoque.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/\" \/>\n<meta property=\"og:site_name\" content=\"Building Nubank\" \/>\n<meta property=\"article:published_time\" content=\"2026-06-18T12:09:16+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-07-01T14:44:07+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/building.nu.com\/wp-content\/uploads\/2026\/06\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1-1024x681.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"681\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Nubank Editorial\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Escrito por\" \/>\n\t<meta name=\"twitter:data1\" content=\"Nubank Editorial\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tiempo de lectura\" \/>\n\t<meta name=\"twitter:data2\" content=\"16 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/\"},\"author\":{\"name\":\"Nubank Editorial\",\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/#\\\/schema\\\/person\\\/462f4f5a8d4ec3ccbc3d661dde00f0a4\"},\"headline\":\"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n\",\"datePublished\":\"2026-06-18T12:09:16+00:00\",\"dateModified\":\"2026-07-01T14:44:07+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/\"},\"wordCount\":3474,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/i0.wp.com\\\/building.nu.com\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1\",\"articleSection\":[\"Data Science & Machine Learning\"],\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/\",\"url\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/\",\"name\":\"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n - Building Nubank\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/i0.wp.com\\\/building.nu.com\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1\",\"datePublished\":\"2026-06-18T12:09:16+00:00\",\"dateModified\":\"2026-07-01T14:44:07+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/#\\\/schema\\\/person\\\/462f4f5a8d4ec3ccbc3d661dde00f0a4\"},\"description\":\"Tras a\u00f1os operando feature stores en diversos flujos de trabajo, aqu\u00ed est\u00e1n algunas lecciones que moldearon nuestro enfoque.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/#breadcrumb\"},\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/#primaryimage\",\"url\":\"https:\\\/\\\/i0.wp.com\\\/building.nu.com\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1\",\"contentUrl\":\"https:\\\/\\\/i0.wp.com\\\/building.nu.com\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1\",\"width\":9023,\"height\":6005},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/building.nu.com\\\/es\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/#website\",\"url\":\"https:\\\/\\\/building.nu.com\\\/es\\\/\",\"name\":\"Building Nubank\",\"description\":\"We make the extraordinary happen\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/building.nu.com\\\/es\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"es\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/building.nu.com\\\/es\\\/#\\\/schema\\\/person\\\/462f4f5a8d4ec3ccbc3d661dde00f0a4\",\"name\":\"Nubank Editorial\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/8c056170dc75ffd365b306a0ac7bea4e51d1cdab52a0c84e6ba0a42f7e2f4633?s=96&d=identicon&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/8c056170dc75ffd365b306a0ac7bea4e51d1cdab52a0c84e6ba0a42f7e2f4633?s=96&d=identicon&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/8c056170dc75ffd365b306a0ac7bea4e51d1cdab52a0c84e6ba0a42f7e2f4633?s=96&d=identicon&r=g\",\"caption\":\"Nubank Editorial\"},\"url\":\"https:\\\/\\\/building.nu.com\\\/es\\\/author\\\/editorial\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n - Building Nubank","description":"Tras a\u00f1os operando feature stores en diversos flujos de trabajo, aqu\u00ed est\u00e1n algunas lecciones que moldearon nuestro enfoque.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/","og_locale":"es_ES","og_type":"article","og_title":"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n - Building Nubank","og_description":"Tras a\u00f1os operando feature stores en diversos flujos de trabajo, aqu\u00ed est\u00e1n algunas lecciones que moldearon nuestro enfoque.","og_url":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/","og_site_name":"Building Nubank","article_published_time":"2026-06-18T12:09:16+00:00","article_modified_time":"2026-07-01T14:44:07+00:00","og_image":[{"width":1024,"height":681,"url":"https:\/\/building.nu.com\/wp-content\/uploads\/2026\/06\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1-1024x681.jpg","type":"image\/jpeg"}],"author":"Nubank Editorial","twitter_card":"summary_large_image","twitter_misc":{"Escrito por":"Nubank Editorial","Tiempo de lectura":"16 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/#article","isPartOf":{"@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/"},"author":{"name":"Nubank Editorial","@id":"https:\/\/building.nu.com\/es\/#\/schema\/person\/462f4f5a8d4ec3ccbc3d661dde00f0a4"},"headline":"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n","datePublished":"2026-06-18T12:09:16+00:00","dateModified":"2026-07-01T14:44:07+00:00","mainEntityOfPage":{"@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/"},"wordCount":3474,"commentCount":0,"image":{"@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/#primaryimage"},"thumbnailUrl":"https:\/\/i0.wp.com\/building.nu.com\/wp-content\/uploads\/2026\/06\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1","articleSection":["Data Science & Machine Learning"],"inLanguage":"es","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/","url":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/","name":"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n - Building Nubank","isPartOf":{"@id":"https:\/\/building.nu.com\/es\/#website"},"primaryImageOfPage":{"@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/#primaryimage"},"image":{"@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/#primaryimage"},"thumbnailUrl":"https:\/\/i0.wp.com\/building.nu.com\/wp-content\/uploads\/2026\/06\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1","datePublished":"2026-06-18T12:09:16+00:00","dateModified":"2026-07-01T14:44:07+00:00","author":{"@id":"https:\/\/building.nu.com\/es\/#\/schema\/person\/462f4f5a8d4ec3ccbc3d661dde00f0a4"},"description":"Tras a\u00f1os operando feature stores en diversos flujos de trabajo, aqu\u00ed est\u00e1n algunas lecciones que moldearon nuestro enfoque.","breadcrumb":{"@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/"]}]},{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/#primaryimage","url":"https:\/\/i0.wp.com\/building.nu.com\/wp-content\/uploads\/2026\/06\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1","contentUrl":"https:\/\/i0.wp.com\/building.nu.com\/wp-content\/uploads\/2026\/06\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1","width":9023,"height":6005},{"@type":"BreadcrumbList","@id":"https:\/\/building.nu.com\/es\/feature-stores-para-ml-en-tiempo-real-parte-2-lecciones-aprendidas-en-produccion\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/building.nu.com\/es\/"},{"@type":"ListItem","position":2,"name":"Feature stores para ML en tiempo real: Parte 2 \u2013 Lecciones aprendidas en producci\u00f3n"}]},{"@type":"WebSite","@id":"https:\/\/building.nu.com\/es\/#website","url":"https:\/\/building.nu.com\/es\/","name":"Building Nubank","description":"We make the extraordinary happen","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/building.nu.com\/es\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"es"},{"@type":"Person","@id":"https:\/\/building.nu.com\/es\/#\/schema\/person\/462f4f5a8d4ec3ccbc3d661dde00f0a4","name":"Nubank Editorial","image":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/secure.gravatar.com\/avatar\/8c056170dc75ffd365b306a0ac7bea4e51d1cdab52a0c84e6ba0a42f7e2f4633?s=96&d=identicon&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/8c056170dc75ffd365b306a0ac7bea4e51d1cdab52a0c84e6ba0a42f7e2f4633?s=96&d=identicon&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/8c056170dc75ffd365b306a0ac7bea4e51d1cdab52a0c84e6ba0a42f7e2f4633?s=96&d=identicon&r=g","caption":"Nubank Editorial"},"url":"https:\/\/building.nu.com\/es\/author\/editorial\/"}]}},"jetpack_shortlink":"https:\/\/wp.me\/pbKBB5-9Ds","jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/building.nu.com\/wp-content\/uploads\/2026\/06\/Nubank_Photoshoot_Brasil_-Fotografia_Edu-Vieira-21-1.jpg?fit=9023%2C6005&ssl=1","_links":{"self":[{"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/posts\/37042","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/users\/178110103"}],"replies":[{"embeddable":true,"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/comments?post=37042"}],"version-history":[{"count":13,"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/posts\/37042\/revisions"}],"predecessor-version":[{"id":37357,"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/posts\/37042\/revisions\/37357"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/media\/37060"}],"wp:attachment":[{"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/media?parent=37042"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/categories?post=37042"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/building.nu.com\/es\/wp-json\/wp\/v2\/tags?post=37042"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}