ADR 0002: Persistencia (MongoDB y PostgreSQL)

Estado

Aceptado

Contexto

El sistema Bazaar requiere gestionar entidades con naturalezas y requisitos de almacenamiento muy distintos.

Por un lado, el Catálogo debe soportar productos de naturaleza heterogénea cuyos atributos varían significativamente según el tipo de ítem (ej: una notebook tiene especificaciones de RAM y procesador, mientras que una remera tiene talle y tela). Un esquema relacional rígido obligaría a usar antipatrones como EAV (Entity-Attribute-Value) o columnas sparse para representar esta variabilidad.

Por otro lado, los dominios de Órdenes y Pagos manejan información financiera y transaccional crítica. Estos requieren garantías estrictas de consistencia, integridad referencial y prevención de condiciones de carrera (por ejemplo, evitar que dos usuarios compren el último ítem disponible de forma simultánea).

Adicionalmente, los Requisitos No Funcionales (RNF) dictados por la cátedra exigen explícitamente el uso de al menos una tecnología de base de datos relacional (SQL) y una no relacional (NoSQL).

Decisión

Decidimos implementar una estrategia de persistencia políglota, asignando el motor de base de datos que mejor se adapte al dominio de cada microservicio:

MongoDB (hosteado en MongoDB Atlas) para el Catalog API: Utilizaremos una base de datos orientada a documentos (NoSQL) para almacenar los productos y sus categorías.
PostgreSQL (hosteado en Supabase) para User API, Orders & Checkout API y Payment API: Usaremos una base de datos relacional (SQL) para los dominios transaccionales. El Carrito (Cart, CartItem) comparte la misma base de datos que Orders & Checkout API, dado que ambos dominios forman parte del mismo servicio y el checkout consume el carrito dentro de una única unidad de trabajo..

Consecuencias

Positivas

Flexibilidad extrema en el Catálogo: Al utilizar documentos JSON en MongoDB, evitamos estructuras rígidas o antipatrones de diseño en SQL (como tablas EAV - Entity-Attribute-Value, o tener decenas de columnas en estado NULL) para manejar los atributos dinámicos de los distintos productos.
Consistencia Transaccional: PostgreSQL nos garantiza cumplimiento ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) para el manejo de stock, la generación de órdenes y la validación de idempotencia en los cobros.
Cumplimiento de RNF: Se satisface plenamente el requisito arquitectónico de la materia de utilizar tecnologías de bases de datos heterogéneas.
Performance de lectura: MongoDB Atlas está optimizado para consultas de lectura rápidas y flexibles, lo cual es ideal para el volumen de búsquedas que recibirá el catálogo.

Negativas y Riesgos

Falta de Integridad Referencial Global: No existen claves foráneas directas entre una Orden (en Postgres) y un Producto (en Mongo). La consistencia entre ambos motores se resuelve a nivel de aplicación: el checkout reserva stock en catalog-api antes de crear la orden, y ante fallo compensa la reserva (ver ADR 0007). Los campos product_name y unit_price se desnormalizan en OrderItem al momento de la compra para desacoplar el historial de órdenes de catalog-api.
Sobrecarga Operativa: El equipo de desarrollo debe administrar, configurar credenciales, realizar backups y mantener esquemas/colecciones en dos proveedores cloud distintos (MongoDB Atlas y Supabase), lo que aumenta la curva de aprendizaje y el mantenimiento de la infraestructura.