Servicios

Servicio responsable de la autenticación en el sistema. Genera y valida access tokens y refresh tokens, y gestiona credenciales de sistemas externos como VTEX, almacenando cookies y sesiones en la base de datos de identidad.

Servicio legado responsable del carrito de compras del cliente. Expone APIs gRPC/HTTP para: - Crear y recuperar carritos por identificador y usuario. - Añadir, actualizar, parchear y eliminar items del carrito. - Gestionar mensajes y comentarios asociados al carrito y a items específicos. - Actualizar datos de envío del carrito (dirección, tipo de entrega, tipo de dirección). - Validar el carrito en base a reglas de negocio, grupos de cliente y contexto de entrega. - Configurar el tipo de sustitución de productos en caso de falta de stock.

⚠ Reemplazado por el microservicio [Carts](/catalog/services/dc-wl-groceries-core-carts) (`dc-wl-groceries-core-carts`, notar la "s" final que distingue a ambos repos), una reimplementación completa que sí cumple con todas las definiciones de la arquitectura White Label y añade mejoras de performance y lógica de negocio. Carts ya está desplegado en producción en `br-prezunic`; el resto de los tenants está en proceso de revisión y rollout progresivo. Este servicio (Cart legacy) se irá deprecando tenant por tenant a medida que Carts se valida y despliega.

Reimplementación completa del carrito de compras del cliente sobre la arquitectura White Label. Expone APIs gRPC/HTTP para: - Crear, recuperar y eliminar carritos por identificador y usuario. - Añadir, actualizar y eliminar items del carrito (patch masivo e individual). - Gestionar mensajes y comentarios asociados al carrito. - Actualizar datos de envío del carrito (dirección, tienda de despacho, tipo de entrega, tipo de dirección) y simular el carrito para un contexto dado. - Validar el carrito en base a reglas de negocio, grupos de cliente y contexto de entrega. - Configurar el tipo de sustitución de productos en caso de falta de stock.

⚠ Reemplaza a [Cart legacy](/catalog/services/dc-wl-groceries-core-cart) (`dc-wl-groceries-core-cart`, sin "s" final). A diferencia del servicio anterior, cumple con todas las definiciones de la arquitectura White Label (cuatro capas, API-first con Protobuf, multi-tenant por FX, eventos vía NATS) y suma mejoras de performance y de lógica de carrito/shipping. Ya está desplegado con éxito en `br-prezunic`; el resto de los tenants está en revisión y se irá habilitando de forma progresiva mientras se depreca el microservicio anterior.

Servicio unificado de catálogo. Consolida en un solo microservicio, un solo contrato y una sola capa de cálculo de precios lo que antes vivía repartido entre [Product Search (legacy)](/catalog/services/dc-wl-groceries-core-search) y [Product Detail (legacy)](/catalog/services/dc-wl-groceries-core-products). Expone 21 RPCs gRPC + grpc-gateway HTTP, API-first sobre Protobuf, para: - Búsqueda/discovery: keyword search, navegación por categoría/colección, facets, autocomplete, autosuggest, productos relacionados, top searches (Constructor.io con fallback a VTEX/VIS). - Producto/detalle: obtención por id/sku/slug/ean (individual y batch), con resolución in-process del producto base (VTEX Catalog) más overlay de stock/precio en tiempo real (VIS). - Enriquecimiento por tenant: productType/food, PPUM formateado, showAddToCart, tags de promoción, info-tags, display ads (CMedia).

⚠ Construido y validado a paridad en vivo contra los dos servicios legacy en los 4 tenants activos (`ar-jumbo`, `ar-disco`, `co-jumbo`, `br-prezunic`), con un harness de paridad offline reproducible. Todavía en pruebas: hay que acelerar la validación para completar la migración y deprecar Search y Product legacy. Reduce ~44% del código de producción y pasa de operar 2 servicios a 1, eliminando el riesgo de que la lógica de precio/medida diverja entre búsqueda y detalle.

Microservicio del dominio "Mis Listas". Gestiona las listas de compras de los usuarios, incluyendo la lista especial de Favoritos. Expone APIs gRPC + grpc-gateway para: - Crear, renombrar y eliminar listas. - Agregar, quitar y actualizar cantidades de ítems. - Vaciar una lista completa. - Consultar listas y su detalle, enriquecidas con datos de catálogo.

⚠ Nuevo microservicio construido sobre la arquitectura White Label. Implementa CQRS con dos roles: `core` (escrituras, persistidas en PostgreSQL) y `query` (lecturas enriquecidas, servidas desde Redis + el microservicio de Catalog). Soporta los cinco tenants: `co-jumbo`, `ar-jumbo`, `ar-disco`, `br-prezunic`, `us-tfm`.

Servicio central del dominio de fidelidad. Expone APIs gRPC/HTTP para: - Resumen de beneficios del cliente (puntos, nivel actual, progreso, categorías). - Consulta de niveles de loyalty y su configuración. - Gestión de la cuenta de cashback (Cencopay), incluyendo saldo, flags y bloqueos. - Gestión de puntos del programa JumboMas (`ar-jumbo`). - Historial de movimientos del programa de lealtad y pagos asociados. - Catálogo de ofertas de loyalty, categorías, vitrinas (showcases) y ofertas disponibles por nivel. - Activación, clip y unclip de ofertas vinculadas al cliente.

⚠ Existen varias APIs especializadas (benefits, Cencopay, offers) que podrían evolucionar en microservicios separados en el futuro, pero hoy se gestionan en un único microservicio. Absorbió la gestión de puntos del programa JumboMas (`ar-jumbo`), que antes vivía en el microservicio de Customers.

Servicio de integración orientado a recibir notificaciones de sistemas externos y traducirlas a eventos internos de la plataforma. Actualmente se utiliza para: - Consumir mensajes de cambios en el CMS / Remote Config a través de colas SQS. - Transformar esos mensajes en eventos propios del sistema. - Publicar dichos eventos en NATS para que otros microservicios actualicen sus configuraciones o caches.

⚠ A pesar del nombre, este servicio no gestiona notificaciones visibles para el usuario final (para eso ver el microservicio de [Push Notifications](/catalog/services/dc-wl-groceries-core-push-notifications)). Actúa como bridge entre Remote Config/CMS y el bus interno (NATS). Se evaluó renombrarlo pero se decidió mantener el nombre actual. Ya está actualizado a la arquitectura White Label.

Servicio responsable del historial y detalle de pedidos del cliente. Expone APIs gRPC/HTTP para: - Obtener el listado de órdenes de un cliente. - Obtener el detalle de una orden puntual. - Obtener la factura (invoice) asociada a una orden.

⚠ Nuevo microservicio construido sobre la arquitectura White Label. Absorbe la responsabilidad de listado y detalle de pedidos que antes vivía dentro de Customers, como parte de la descomposición de ese servicio sobrecargado.

Servicio legado responsable de la ficha de producto. Expone APIs HTTP para obtener información detallada de un producto, utilizando un modelo de datos muy similar al de Search, pero enriquecido con: - Detalles adicionales del producto. - Ingredientes y atributos específicos. - Recomendaciones de productos relacionados. - Información extendida para la pantalla de detalle.

⚠ La discusión sobre desmantelarlo y consolidar con Search ya se resolvió: el nuevo microservicio [Catalog](/catalog/services/dc-wl-groceries-core-catalog) (`dc-wl-groceries-core-catalog`) unifica ambas responsabilidades. Catalog está validado a paridad contra este servicio en los 4 tenants activos y en fase de pruebas antes del cutover; hay que acelerar esa validación. Una vez completada, este servicio se depreca.

Servicio legado responsable de la búsqueda y descubrimiento de productos. Expone APIs gRPC/HTTP para: - Top searches y sugerencias de búsqueda. - Autocomplete y autosuggest combinando términos y productos relacionados. - Búsqueda de productos por keyword, categoría y colección. - Obtención de facets y opciones de filtrado para resultados de búsqueda. - Información de paginación, ordenación y filtros aplicados sobre los resultados.

⚠ La discusión sobre consolidar con Product ya se resolvió: el nuevo microservicio [Catalog](/catalog/services/dc-wl-groceries-core-catalog) (`dc-wl-groceries-core-catalog`) unifica ambas responsabilidades. Catalog está validado a paridad contra este servicio en los 4 tenants activos y en fase de pruebas antes del cutover; hay que acelerar esa validación. Una vez completada, este servicio se depreca.

Servicio responsable de calcular y devolver promociones aplicables a productos y/o carritos. Implementa reglas de priorización para determinar qué promociones son más beneficiosas para el usuario en un contexto dado, resolviendo conflictos entre múltiples ofertas y combinaciones posibles.

⚠ Migrado a la arquitectura White Label y ya expone interfaz gRPC (ingest y query) además de HTTP, alineado con el resto de los servicios core de la plataforma.

Servicio responsable del envío de notificaciones push al cliente. Expone una API gRPC + grpc-gateway para disparar el envío de una notificación push a los dispositivos registrados de un usuario.

⚠ Nuevo microservicio construido desde cero sobre la arquitectura White Label. Separa el envío de notificaciones push (canal directo al dispositivo) de la bandeja de notificaciones/inbox que sigue gestionando Customers.

Servicio responsable de las recomendaciones de productos. Actúa como proxy hacia un proveedor externo de recomendaciones y expone APIs gRPC + grpc-gateway para: - Productos frecuentes: productos que el usuario compra habitualmente, basado en historial de compras. - Bestsellers: productos más vendidos del catálogo, sin personalización. - Productos similares: productos relacionados a un SKU dado. - Productos elegidos (Pensados para ti): recomendaciones personalizadas cruzando userId con un conjunto de SKUs.

⚠ Migración a la arquitectura White Label completada: ahora sigue la estructura de cuatro capas, expone gRPC/Protobuf con grpc-gateway, y usa el modelo multi-tenant por FX en lugar de HTTP/Gin con structs propios.

Servicio legado que maneja autenticación y sesiones de usuarios, incluyendo generación de tokens y gestión de credenciales para sistemas externos como VTEX.

⚠ Deprecado por completo en favor del servicio [Auth](/catalog/services/dc-wl-groceries-core-auth), que absorbió todas sus funcionalidades y ya cumple con la arquitectura White Label.

Proxy que concentra en un solo lugar las credenciales y configuración de VTEX (base URL, app key, app token) de todos los tenants. Expone un API HTTP (Rust/Axum) para que otros servicios y herramientas accedan a VTEX sin que cada uno gestione sus propias credenciales por tenant.

⚠ Vive dentro del monorepo `dc-wl-control-panel` (herramientas internas de desarrollo/operación), pero se despliega como servicio independiente (Dockerfile, k8s, Tiltfile propios). Pertenece al nuevo dominio de infraestructura, transversal al resto de los microservicios que consumen VTEX.