500,000 dolares donados. 2,000+ productos listados. 350+ vendedores activos en todo Mexico. Esas no son metricas de vanidad. Son el resultado de decisiones de arquitectura deliberadas que nuestro equipo tomo al construir Platia, el marketplace B2B circular lider de Mexico. Este articulo desglosa las decisiones tecnicas, compensaciones y lecciones aprendidas al construir una plataforma que convierte inventario excedente en donaciones caritativas en cuatro verticales: hogar, eventos, hoteles y restaurantes.

Si eres CTO o VP de Ingenieria evaluando arquitectura de marketplace para una plataforma B2B, esta es la profundizacion tecnica que deseariamos haber tenido antes de empezar.

El Problema: Comercio Circular B2B en Mexico

El inventario excedente B2B es un mercado masivo y desatendido. Los hoteles tienen muebles sin usar despues de renovaciones. Los organizadores de eventos tienen decoracion sobrante despues de producciones grandes. Los restaurantes tienen exceso de equipo cuando reducen operaciones o cierran. Tradicionalmente, este excedente va a tiraderos o lo recogen intermediarios informales a una fraccion de su valor.

El angulo de economia circular agrega complejidad. Platia no solo conecta compradores y vendedores. Rastrea el impacto caritativo de cada transaccion. Cuando un vendedor dona inventario excedente a traves de la plataforma, el sistema registra el valor de la donacion y lo dirige a organizaciones sin fines de lucro verificadas. Esta no es una funcionalidad agregada. Es nucleo del producto.

Tres problemas hacian esto no trivial:

Brecha de confianza en transacciones B2B. Los compradores empresariales no navegan como consumidores. Necesitan precios por volumen, verificacion de cantidades y garantia de que los bienes excedentes cumplan estandares de calidad.
Procesos manuales en todas partes. El inventario excedente existente se gestionaba a traves de grupos de WhatsApp, llamadas telefonicas y hojas de calculo. No habia una capa de descubrimiento centralizada.
El rastreo de impacto requiere infraestructura de datos. Para reportar crediblemente 500,000+ dolares en donaciones, cada transaccion necesitaba pistas de auditoria, generacion de recibos y agregacion en paneles en tiempo real a traves de cuatro verticales distintas.

Nuestro equipo en 4M Labs fue contactado para arquitectar y construir la plataforma desde cero. Asi es como lo abordamos.

Decisiones de Arquitectura y Compensaciones

UX del Marketplace: B2B No es B2C

La primera decision de arquitectura fue rechazar los patrones de marketplace B2B2C. La mayoria de los frameworks de marketplace (Medusa, Sharetribe, Shopify multi-vendor personalizado) optimizan para comportamiento de navegacion del consumidor: navegar, filtrar, agregar al carrito, pagar. Platia necesitaba un flujo fundamentalmente distinto.

Los compradores empresariales en Platia buscan por categoria, negocian precios, solicitan cotizaciones para pedidos por volumen y verifican la credibilidad del vendedor antes de comprar. El flujo de compra no es lineal. Es conversacional. Un hotel que compra 200 sillas no va a hacer clic en "Comprar Ahora". Va a enviar un mensaje al vendedor, negociar, solicitar una muestra y luego hacer un pedido de compra.

Que construimos en su lugar:

Sistema de solicitud de cotizaciones. Los compradores envian RFQs (Request for Quotes) con cantidad, requisitos de entrega y cronograma. Los vendedores responden con precios personalizados. Esto se acerca mas a compras B2B que a comercio electronico.
Capa de verificacion de vendedores. Cada vendedor pasa por un proceso de verificacion manual antes de listar productos. Construimos un panel de administracion que rastrea estado de verificacion, documentacion empresarial y revisiones de calidad de productos.
Esquemas de productos especificos por vertical. Una silla en la vertical de "hogar" tiene atributos distintos a una silla en la vertical de "eventos". El mobiliario del hogar necesita dimensiones, material, grado de condicion. El mobiliario de eventos necesita disponibilidad de renta, logistica de montaje/desmontaje y niveles de precios por volumen. Modelamos estas como extensiones de esquema separadas en lugar de un esquema unico flexible.

La compensacion: este enfoque es mas dificil de mantener. Cada vertical tiene su propio modelo de producto, flujo de listado y configuracion de busqueda. Un marketplace generico seria mas facil de construir pero fallaria en usabilidad para compradores o vendedores. Elegimos UX especifica por vertical sobre simplicidad de ingenieria.

Onboarding Self-Service de Vendedores

350+ vendedores no ocurrieron por accidente. Necesitabamos un flujo de onboarding self-Service que no sacrificarara calidad. El desafio de arquitectura: como dejas que cualquiera se registre y liste productos manteniendo una capa de confianza para compradores?

La solucion fue un pipeline de onboarding por etapas:

Registro. El vendedor proporciona informacion empresarial (RFC, razon social, categoria). La validacion basica corre inmediatamente.
Verificacion. El administrador revisa la documentacion. Este es un paso manual. Decidimos contra la automatizacion completa porque la confianza es el producto en marketplaces B2B.
Listado de productos. Los vendedores verificados pueden listar productos. Cada listado pasa por una cola de revision ligera antes de publicarse.
Rastreo de desempeno. Una vez en linea, los vendedores acumulan un puntaje de confianza basado en tasa de completacion de transacciones, resenas de compradores y tiempo de respuesta.

El modelo de datos soporta este pipeline:

Seller {
  id: UUID
  businessName: string
  rfc: string
  verificationStatus: 'pending' | 'verified' | 'rejected'
  trustScore: number (0-100)
  verticals: Vertical[]
  products: Product[]
  donations: Donation[]
}

Product {
  id: UUID
  sellerId: FK
  vertical: 'home' | 'events' | 'hotels' | 'restaurants'
  schema: JSONB (atributos especificos por vertical)
  conditionGrade: 'A' | 'B' | 'C'
  quantity: number
  pricePerUnit: number
  donationEligible: boolean
}

El campo schema especifico por vertical usa JSONB en lugar de columnas rigidas. Esta fue una compensacion deliberada: perdemos algo de optimizacion de consultas pero ganamos flexibilidad para soportar diferentes tipos de producto sin migraciones de esquema cada vez que se necesita un nuevo atributo. Para un marketplace a nuestra escala actual, esta es la decision correcta. Si alcanzamos 50,000+ listados, podriamos reconsiderar con un enfoque mas estructurado.

Panel de Impacto: Rastreando 500,000+ en Donaciones

El panel de impacto no es un reporte posterior. Es una funcionalidad de primera clase. Tanto vendedores como compradores ven el rastreo de donaciones en tiempo real. El sistema necesita agregar datos a traves de transacciones, calcular montos de donacion y presentarlos de manera auditable y creible.

Arquitectura para rastreo de impacto:

Event sourcing para donaciones. Cada donacion se registra como un evento inmutable. No actualizamos registros de donacion. Anexamos eventos nuevos (creada, verificada, desembolsada, confirmada). Esto nos da una pista de auditoria completa.
Vista materializada para paneles. El panel lee desde una tabla de agregacion pre-computada que se actualiza en un cronograma (cada 15 minutos). Esto evita agregaciones costosas en tiempo real en cada carga de pagina.
Integracion webhook con procesadores de pago. Cuando una transaccion se completa, un webhook activa el calculo de donacion. El sistema calcula el monto de donacion (porcentaje configurable del valor de transaccion) y crea el registro de donacion.

El flujo de donacion:

Transaccion se completa
  -> Webhook se dispara
  -> Calculadora de donacion corre
  -> Registro de donacion creado (estado: pendiente)
  -> Cola de verificacion del administrador (para montos > $10,000 MXN)
  -> Donacion confirmada
  -> Desembolso programado a organizacion sin fines de lucro
  -> Agregacion del panel actualizada

Inicialmente intentamos agregacion en tiempo real para el panel. Era lento. Consultar millones de registros de transacciones para computar totales acumulados en cada carga de pagina causaba latencia notable. El enfoque de vista materializada redujo el tiempo de carga del panel de 2.3 segundos a menos de 200 milisegundos. La obsolescencia de 15 minutos es aceptable porque los montos de donacion no cambian en tiempo real.

Descubrimiento por Categoria en Cuatro Verticales

Cuatro verticales (hogar, eventos, hoteles, restaurantes) significan cuatro taxonomias de productos diferentes, cuatro personas de comprador distintas y cuatro estrategias de busqueda diferentes. La arquitectura necesita soportar descubrimiento especifico por vertical sin duplicar toda la plataforma.

Arquitectura de busqueda:

Elasticsearch con analizadores especificos por vertical. Cada vertical tiene su propio indice con mapeos personalizados. La busqueda de mobiliario del hogar prioriza material y dimensiones. La busqueda de equipo hotelero prioriza cantidad y logistica de entrega. La busqueda de suministros de eventos prioriza fechas de disponibilidad y requisitos de montaje.
Navegacion facetada por vertical. La barra lateral de filtros cambia segun la vertical activa. Los compradores del hogar ven filtros para material, color y condicion. Los compradores de hoteles ven filtros para cantidad, cronograma de entrega y precios por volumen.
Descubrimiento cross-vertical. Los compradores pueden navegar entre verticales cuando buscan categorias generales (por ejemplo, "mobiliario" aparece en hogar y eventos). Manejamos esto con un indice de busquete unificado que etiqueta resultados por vertical, permitiendo a los compradores filtrar o expandir su busqueda.

La compensacion aqui es la complejidad de gestion de indices. Mantener cuatro indices verticales separados mas un indice unificado cross-vertical significa mas infraestructura y mas sobrecarga operativa. La alternativa (indice unico con campo de vertical) seria mas simple pero degradaria la calidad de busqueda porque cada vertical necesita diferentes puntuaciones de relevancia.

Capa de Confianza para Compradores Empresariales

Los compradores B2B necesitan mas senales de confianza que calificaciones de estrellas. Nuestra arquitectura de confianza incluye:

Insignias de verificacion de vendedores. Los negocios verificados obtienen una insignia visible en resultados de busqueda y listados.
Historial de transacciones. Los compradores pueden ver cuantas transacciones ha completado un vendedor, volumen total y tiempo promedio de respuesta.
Calificacion de condicion. Cada listado de producto incluye un grado de condicion (A, B, C) con criterios estandarizados. Grado A es como nuevo. Grado B muestra desgaste menor. Grado C es funcional pero muestra uso significativo.
Resolucion de disputas. La plataforma incluye un flujo de disputa ligero donde los compradores pueden senalar problemas dentro de 48 horas de la entrega. Los vendedores tienen 72 horas para responder. La escalacion va al administrador de Platia.

Debatimos construir un sistema de escrow completo. Decidimos no hacerlo para el lanzamiento inicial. El escrow agrega complejidad significativa (retenciones de pago, condiciones de liberacion, activadores de disputa) y no estaba bloqueando nuestro caso de uso principal. Los vendedores y compradores en Platia tienden a establecer relaciones continuas. La primera transaccion puede pasar por la plataforma, pero los pedidos recurrentes a menudo ocurren directamente. Esto es realista para B2B en Mexico, y la arquitectura lo contempla.

Stack Tecnologico

Las decisiones tecnologicas estuvieron impulsadas por la composicion del equipo, el cronograma y la necesidad de iteracion rapida.

Frontend:

React 18 con TypeScript. El equipo tenia experiencia profunda en React. TypeScript era innegociable para un codebase de este tamano.
TanStack Router. Enrutamiento basado en archivos con seguridad de tipos. Mejor que React Router para layouts anidados complejos, que un marketplace con cuatro verticales requiere.
Tailwind CSS. Desarrollo rapido de UI sin la sobrecarga de un diseno de sistema. Para un marketplace con muchas paginas, Tailwind nos permitio entregar UI consistente sin un equipo de diseno dedicado.
React Query (TanStack Query). Gestion de estado del servidor. Critico para un marketplace pesado en datos donde los listados de productos, resultados de busqueda y datos del panel necesitan cache, refetching en segundo plano y actualizaciones optimistas.

Backend:

Node.js con Express. Elegido por experiencia del equipo. El equipo era mas productivo en TypeScript de extremo a extremo.
PostgreSQL. Datos relacionales con JSONB para esquemas de productos especificos por vertical. Consideramos MongoDB para el esquema flexible pero decidimos que PostgreSQL nos daba mejores capacidades de consulta para las funcionalidades de reportes y paneles.
Elasticsearch. Motor de busqueda dedicado para descubrimiento de productos. La busqueda de texto completo de PostgreSQL no era suficiente para la busqueda facetada y especifica por vertical que necesitabamos.
Redis. Gestion de sesiones, cache para consultas calientes (listados de productos, resultados de busqueda) y limitacion de tasa.

Infraestructura:

Contenedores Docker en un VPS. Empezamos con un solo VPS para el MVP. A medida que el trafico crecio, nos movimos a una configuracion multi-contenedor con Docker Compose. Esto fue pragmatico. No necesitabamos la complejidad de Kubernetes a nuestra escala.
Cloudflare para CDN y proteccion DDoS. Activos estaticos, cache de API y capa de seguridad.
GitHub Actions para CI/CD. Testing automatizado y despliegue en cada push a main.

Por que no serverless? Para un marketplace con gestion de estado compleja, funcionalidades en tiempo real (negociaciones de cotizaciones) y consultas de busqueda pesadas, serverless habria introducido latencia y complejidad de debugging que superaban los beneficios de escalabilidad. Los contenedores nos dieron desempeno predecible y debugging mas simple durante la fase critica de crecimiento inicial.

Lecciones Aprendidas

Que hariamos diferente:

Construir el panel de administracion primero. Construimos las experiencias de vendedor y comprador primero, y tuvimos que adaptar las herramientas de administracion para verificacion, resolucion de disputas y gestion de donaciones. El panel de administracion deberia haber sido lo primero que construimos porque define los flujos operativos que la plataforma soporta.
Invertir en busqueda desde el principio. Empezamos con busqueda de texto completo de PostgreSQL y migramos a Elasticsearch despues del lanzamiento. La migracion fue dolorosa. Tuvimos que reconstruir indices, actualizar logica de consultas y reentrenar al equipo. Si la busqueda es nucleo de tu marketplace, empieza con un motor de busqueda dedicado.
Validacion de esquema en listados de productos. Permitimos demasiada flexibilidad en los listados iniciales de productos. Algunos vendedores subieron datos incompletos o inconsistentes. Agregar validacion de esquema mas estricta por vertical habria reducido el trabajo de limpieza que tuvimos que hacer despues.

Que funciono bien:

Modelos de producto especificos por vertical. El enfoque de esquema JSONB para atributos de productos fue la decision correcta. Nos dio flexibilidad sin la sobrecarga de migraciones de esquema. Cada vertical puede evolucionar independientemente.
Vistas materializadas para paneles. Las agregaciones pre-computadas con refres periodico es el patron correcto para paneles de reportes. La agregacion en tiempo real es una trampa para marketplaces con volumenes de transacciones crecientes.
Onboarding por etapas con verificacion manual. El paso de verificacion manual ralento el onboarding de vendedores pero maintuvo la calidad. En marketplaces B2B, la confianza es el producto. Automatizar la verificacion demasiado pronto habria degradado la experiencia del comprador.
Event sourcing para donaciones. Los eventos de donacion inmutables nos dieron una pista de auditoria completa. Cuando donadores o organizaciones sin fines de lucro preguntaban por historial de transacciones, podiamos reconstruir la linea de tiempo completa sin instrumentacion adicional.

Resultados

Las decisiones de arquitectura estan validadas por los numeros:

2,000+ productos listados en cuatro verticales (hogar, eventos, hoteles, restaurantes)
350+ vendedores activos incorporados a traves del pipeline self-service
500,000+ dolares donados a organizaciones sin fines de lucro verificadas
4 verticales operando con esquemas de productos y busqueda especificos por vertical
platia.com.mx en linea y sirviendo a compradores B2B en todo Mexico

La plataforma esta procesando transacciones, rastreando donaciones y escalando sin cambios arquitectonicos mayores. Las decisiones iniciales, PostgreSQL con JSONB, Elasticsearch para busqueda, vistas materializadas para paneles, event sourcing para donaciones, se han mantenido.

Que Le Diriamos a Otros Constructores de Marketplaces

Si estas construyendo un marketplace B2B, aqui esta el consejo de arquitectura que dariamos basado en la experiencia de Platia:

B2B no es B2C con carritos mas grandes. El flujo del comprador, los requisitos de confianza y los patrones de negociacion son fundamentalmente diferentes. No intentes adaptar un framework de marketplace B2B2C. Construye para el comportamiento especifico de tu comprador.
Empieza con una vertical, luego expande. Lanzamos con dos verticales (hogar y eventos) y agregamos hoteles y restaurantes despues de validar la arquitectura central. Agregar las cuatro de una vez habria sido un error.
Invierte en el panel de administracion desde el primer dia. Los flujos operativos definen lo que la plataforma puede y no puede hacer. Construye las herramientas de administracion primero, luego construye las experiencias de comprador y vendedor alrededor de esos flujos.
Elige PostgreSQL sobre MongoDB para marketplaces. La integridad relacional, la flexibilidad de JSONB y las capacidades de reportes de PostgreSQL son mas adecuadas para modelos de datos de marketplace que el modelo de documentos de MongoDB.
Busqueda dedicada desde el inicio. Si el descubrimiento de productos es tu propuesta de valor central, no uses busqueda de texto completo de base de datos. Elasticsearch o Meilisearch te ahorraran dolor de migracion despues.
Event sourcing para registros financieros. Cualquier funcionalidad que involucre dinero (donaciones, transacciones, pagos) se beneficia de registros de eventos inmutables. La pista de auditoria vale la complejidad.

Construyendo un marketplace B2B? Agenda una llamada con nuestro equipo. Hemos enviado plataformas como Platia y podemos ayudarte a tomar las decisiones de arquitectura correctas para tu mercado especifico.