Como Construir una Plataforma de Subastas en Linea [Guia Tecnica 2025]

Las plataformas de subastas pertenecen a una categoria poco comun de software en la que equivocarse en los fundamentos tecnicos no solo produce una mala experiencia de usuario — cuesta dinero directamente, erosiona la confianza y, en sectores regulados, genera responsabilidad legal. Una puja que se registra un segundo tarde. Una condicion de carrera que permite que dos compradores ganen el mismo lote. Un temporizador que corre mas rapido en un dispositivo que en otro. Un pago que se autoriza pero nunca se captura. Estos no son casos extremos. Son las cosas que ocurren cuando se construye una plataforma de subastas de la misma manera que se construiria un sitio de comercio electronico estandar.

Hemos construido plataformas de subastas y marketplaces en los sectores de arte, antiguedades, equipos industriales, ganado, vehiculos y propiedades comerciales. El hilo comun en todos esos sectores es que la tecnologia es genuinamente dificil — no porque requiera ingenieria exotica, sino porque exige un nivel de precision, consistencia y coordinacion en tiempo real que la mayoria de las aplicaciones web simplemente no tiene.

Esta guia cubre el panorama tecnico completo: las decisiones de arquitectura, las opciones de infraestructura, las funcionalidades necesarias y los errores que vemos repetidamente en equipos que subestiman el problema. Si estas evaluando si construir, comprar o asociarte para lanzar una plataforma de subastas al mercado en 2025, este es el analisis mas tecnicamente honesto que podemos ofrecerte.

---

Tipos de Formatos de Subasta

La primera decision que da forma a todos los requisitos tecnicos posteriores es: que tipo de subasta vas a ejecutar realmente? Esta no es una decision de producto que ocurre despues de construir la plataforma. Es una restriccion fundamental que determina tu modelo de datos, tus requisitos en tiempo real, el comportamiento del temporizador y la logica del motor de pujas.

Subasta Ascendente Inglesa

El formato mas conocido. Un lote se abre a un precio inicial, los pujadores compiten colocando pujas cada vez mas altas y la puja mas alta al cierre gana. Este es el formato utilizado por Sotheby's, Christie's, eBay (en su forma original) y la mayoria de las subastas de ganado y vehiculos.

Desde el punto de vista tecnico, este formato es enganosamente exigente. Cada puja debe validarse contra la puja mas alta actual en tiempo real, lo que significa que no se pueden tolerar lecturas desactualizadas. Dos pujadores pueden enviar pujas con milisegundos de diferencia — tu sistema debe resolver cual llego primero, aplicarla de forma atomica y propagar inmediatamente el nuevo estado a todos los clientes conectados. A escala (cientos de lotes simultaneos, miles de pujadores conectados), los requisitos de rendimiento y consistencia se convierten en problemas serios de ingenieria.

Subasta Descendente Holandesa

El precio comienza alto y disminuye a una tasa definida hasta que un pujador lo acepta — momento en el que la subasta se cierra de inmediato. Se utiliza en mercados de flores, mercados de pescado y algunas plataformas de liquidacion de propiedades comerciales.

El perfil tecnico aqui es diferente. No necesitas gestionar la competencia concurrente de pujas de la misma manera, pero si necesitas un calculo de precio altamente preciso y con autoridad del servidor en cada intervalo de marcacion. El temporizador no es cosmetico — determina directamente el precio de la transaccion. Una deriva del cliente de incluso unos pocos cientos de milisegundos puede generar disputas sobre cual fue el precio aceptado. El calculo del precio en el lado del servidor con una marca de tiempo firmada en cada evento de aceptacion es obligatorio.

Subasta de Sobre Cerrado (Primer Precio y Segundo Precio)

Todos los pujadores envian su puja maxima sin ver las pujas de los demas. En la subasta de sobre cerrado de primer precio, el mejor pujador paga lo que pujó. En la de segundo precio (Vickrey), paga el segundo importe mas alto. Se utiliza en licitaciones gubernamentales, concursos de propiedades comerciales y algunos mercados de coleccionistas especializados.

Los requisitos tecnicos aqui son diferentes una vez mas — menos complejidad en tiempo real, pero considerablemente mas sensibilidad en torno a la confidencialidad de las pujas y la integridad de la revelacion. Las pujas deben almacenarse cifradas o, como minimo, inaccesibles para todas las partes (incluido tu propio equipo de operaciones en algunos contextos regulatorios) hasta la ventana de revelacion. El registro de auditoria para subastas de sobre cerrado se examina con frecuencia, por lo que los esquemas de compromiso criptografico o, como minimo, el registro de eventos inmutable no son opcionales.

Subastas con Precio de Reserva

No es un formato independiente, sino un modificador que se aplica a cualquiera de los anteriores. Un lote tiene un precio minimo oculto (la reserva). Si la puja no alcanza ese umbral, el vendedor no esta obligado a vender. Si lo alcanza, se dice que la subasta esta "en el mercado."

Esto agrega estado a tu modelo de lote — cada lote necesita rastrear si se ha cumplido la reserva, y ese estado debe comunicarse a los pujadores sin revelar el importe de la reserva en si. Tu motor de pujas necesita evaluar las condiciones de reserva en cada puja y activar las notificaciones correspondientes ("la reserva se ha cumplido").

Subastas Online Temporizadas vs. En Vivo/Simulcast

Las subastas online temporizadas se ejecutan de forma asincrona — los lotes estan abiertos durante una ventana definida (horas, dias) y los pujadores participan en cualquier momento. Las subastas en vivo son sincronas — un subastador humano controla el ritmo y los pujadores en la sala y en linea compiten simultaneamente. El simulcast combina ambas: un subastador en vivo dirige la sala mientras una plataforma online introduce las pujas externas en tiempo real.

Las subastas temporizadas son significativamente mas faciles de construir. Los requisitos en tiempo real son modestos — necesitas actualizaciones WebSocket confiables, pero el ritmo es lo suficientemente lento como para que la consistencia eventual en unos pocos cientos de milisegundos sea aceptable.

El simulcast es uno de los problemas mas dificiles en el software de subastas. Estas conectando una sala fisica que opera a la velocidad de la conversacion humana con una plataforma online que opera a la velocidad de la red, mientras mantienes la paridad de pujas, gestionas la capacidad del subastador para aceptar o rechazar pujas y aseguras que la latencia en el lado online no ponga en desventaja a los pujadores respecto a la sala. Si tu cliente planea ejecutar simulcast desde el primer dia, la arquitectura debe disenarse para ello — la adaptacion posterior es costosa.

---

Componentes Tecnicos Principales de una Plataforma de Subastas

Motor de Pujas en Tiempo Real

El motor de pujas es el corazon del sistema. Recibe las solicitudes de puja, las valida, las aplica y transmite los cambios de estado. Todos los demas componentes dependen de su correcto funcionamiento y rendimiento.

WebSocket vs. Long-Polling vs. Server-Sent Events

La eleccion del transporte en tiempo real tiene implicaciones significativas:

• WebSockets (via Socket.io o ws nativo) proporcionan conexiones persistentes full-duplex. Los pujadores envian pujas y reciben actualizaciones por la misma conexion. Esta es la opcion correcta para subastas en vivo y simulcast donde la plataforma necesita enviar actualizaciones con alta frecuencia y recibir solicitudes de puja en tiempo real. La sobrecarga de gestion de conexiones (logica de reconexion, heartbeats, gestion de salas/canales) es considerable pero bien comprendida.
• Server-Sent Events (SSE) son unidireccionales — el servidor envia actualizaciones al cliente, pero las solicitudes se realizan mediante peticiones HTTP separadas. Esto funciona bien para subastas temporizadas donde el patron de interaccion es principalmente "ver actualizaciones, enviar una puja ocasionalmente." SSE es mas simple de implementar y escala mejor detras de balanceadores de carga HTTP/2, pero pierde la elegancia de una unica conexion para experiencias verdaderamente interactivas.
• Long-polling es un patron heredado que debe evitarse en nuevas plataformas de subastas. Crea carga innecesaria en el servidor, introduce latencia y complica la gestion de estado.

Nuestra recomendacion predeterminada para plataformas de subastas es WebSocket con Socket.io para salas (lotes), combinado con una capa Redis pub/sub para que los eventos de puja puedan transmitirse a multiples instancias de servidor sin requerir sesiones fijas.

Arquitectura del Motor de Pujas

El motor de pujas debe ser sin estado en la capa de aplicacion. Todo el estado autoritativo — puja mas alta actual, tabla de incrementos de puja, estado del lote, estado de la reserva — vive en un almacen de datos que todas las instancias pueden leer de forma consistente. El flujo en cada solicitud de puja:

1. Recibir puja del cliente autenticado
2. Validar autenticacion y estado activo del lote
3. Adquirir bloqueo atomico sobre el lote (ver manejo de condiciones de carrera a continuacion)
4. Leer la puja mas alta actual del almacen autoritativo
5. Validar el importe de la puja contra el incremento minimo
6. Validar la elegibilidad del pujador (no es el pujador mas alto actual, no esta suspendido)
7. Escribir el nuevo registro de puja en la base de datos
8. Actualizar el estado del lote en cache
9. Liberar bloqueo
10. Publicar evento de puja en el canal pub/sub
11. Todas las instancias conectadas reciben el evento y envian la actualizacion a sus clientes conectados

Este flujo, ejecutado correctamente, garantiza que no se puedan aplicar dos pujas simultaneamente, el estado siempre sea consistente y cada cliente conectado vea la misma informacion dentro de la latencia del ciclo pub/sub.

Validacion de Pujas y Manejo de Condiciones de Carrera

Las condiciones de carrera en plataformas de subastas no son teoricas. Cuando un lote popular esta cerrando, es comun recibir docenas de pujas en un solo segundo. Sin controles de concurrencia adecuados, multiples pujas pueden leer el mismo "puja mas alta actual" simultaneamente, todas pasar la validacion y todas intentar escribir — produciendo estado inconsistente, ganadores incorrectos y disputas.

Bloqueo Optimista

Un enfoque es el bloqueo optimista a nivel de base de datos. Cada registro de lote lleva un numero de version. Cuando tu motor lee el estado actual y luego intenta escribir una nueva puja, incluye la version que leyo como condicion: UPDATE lots SET highest_bid = $1, version = version + 1 WHERE id = $2 AND version = $3. Si otra transaccion confirmo una escritura entre la lectura y la escritura, la condicion de version falla, la escritura se rechaza y el motor reintenta con el estado actualizado. Esto funciona bien para concurrencia moderada.

Operaciones Atomicas con Redis

Para escenarios de alta concurrencia — cientos de pujas por segundo en un lote que esta cerrando — preferimos operaciones atomicas de Redis usando scripts Lua o las primitivas SET NX / INCR. Redis es de un solo hilo para la ejecucion de comandos, lo que significa que un script Lua que lee, valida y escribe el estado de la puja se ejecuta atomicamente sin ningun riesgo de intercalado. El patron:

-- Script Lua (ejecutado atomicamente por Redis)
local current = redis.call('GET', KEYS[1])  -- current highest bid
if tonumber(ARGV[1]) > tonumber(current) then
  redis.call('SET', KEYS[1], ARGV[1])
  return 1  -- bid accepted
else
  return 0  -- bid rejected (outbid)
end

La escritura en la base de datos ocurre entonces de forma asincrona como registro duradero, con Redis sirviendo como fuente de verdad autoritativa para el estado de las pujas en vivo. Este enfoque escala a miles de pujas concurrentes sin contension de bloqueos.

La Importancia de la Autoridad del Lado del Servidor

Una regla que no puede enunciarse con suficiente frecuencia: el servidor siempre es autoritativo. La validacion de pujas en el lado del cliente es solo UX — evita envios claramente invalidos pero nunca debe confiarse en ella como la ultima palabra. Hemos visto plataformas donde el temporizador de cuenta regresiva del lado del cliente determina cuando un lote "cierra" desde la perspectiva del pujador, permitiendo que se envien pujas despues de que el lote haya cerrado realmente en el servidor. Esto crea disputas y, en algunos contextos regulatorios, exposicion legal.

Gestion de Lotes y Catalogo

El catalogo de lotes es la columna vertebral de contenido de la plataforma. Como minimo, cada lote necesita:

• Identidad del lote: numero de lote, titulo, descripcion, notas de procedencia o estado
• Medios: multiples imagenes con ordenamiento, video opcional, adjuntos de documentos opcionales (certificados, tasaciones, informes)
• Parametros de precio: puja inicial, precio de reserva (si aplica), tabla de incrementos de puja, precio de compra inmediata (si aplica)
• Tiempos: hora de apertura del lote, hora de cierre del lote, logica de extension automatica
• Maquina de estado: draft, scheduled, open, closing, sold, unsold, withdrawn
• Contexto de venta: a que venta en subasta pertenece este lote, cual es su secuencia dentro de esa venta

Extension Automatica (Cierre Suave)

Una funcionalidad que mejora dramaticamente el compromiso del pujador y los ingresos de la plataforma es el cierre suave (tambien llamado modo "a la una, a las dos, a las tres"). Cuando se realiza una puja dentro de una ventana definida antes de la hora de cierre de un lote (tipicamente los ultimos 2-5 minutos), la hora de cierre se extiende automaticamente por un intervalo fijo (tipicamente 2-3 minutos). Esto imita la dinamica de una sala en vivo donde el subastador no cerrara un lote mientras aun haya manos en el aire.

La logica parece simple pero tiene casos extremos sutiles: ¿cual es el numero maximo de extensiones permitidas? ¿Que sucede si un lote esta en extension automatica cuando llega la hora de fin programada de la venta? Estos deben definirse en tu modelo de lote e implementarse de forma consistente.

Identidad del Comprador/Vendedor y KYC

Las subastas son transacciones que dependen de la confianza. A diferencia de un proceso de pago estandar en comercio electronico donde la identidad tiene relativamente bajo riesgo, una plataforma de subastas necesita saber que:

• Los pujadores son quienes dicen ser
• Los pujadores tienen capacidad financiera para honrar las pujas ganadoras
• Los vendedores tienen titulo legitimo sobre lo que estan vendiendo
• Ninguna de las partes esta en una lista de sanciones o sujeta a senales de alerta ALD

Los requisitos de KYC varian segun el sector. Los mercados de arte que operan por encima de ciertos umbrales estan sujetos a la Directiva de Lucha contra el Blanqueo de Capitales en el Reino Unido y la UE. Las subastas de vehiculos tienen requisitos de verificacion de titulo. Las subastas de equipos industriales tratan con regulaciones de control de exportaciones. La capa KYC de tu plataforma debe definirse con un profesional de cumplimiento, no solo con un ingeniero.

Desde el punto de vista de la implementacion tecnica, el KYC se gestiona tipicamente a traves de uno de varios proveedores externos — Onfido, Jumio, Veriff o Stripe Identity — que manejan la captura de documentos, verificaciones de vida y escrutinio de listas de vigilancia. Tu plataforma integra su SDK en el flujo de registro, almacena un indicador de estado KYC en el registro del usuario y condiciona el acceso a las pujas a ese estado.

Gestion del Temporizador

El temporizador es uno de los componentes mas debatidos en cualquier plataforma de subastas, y uno de los que se implementa incorrectamente con mas frecuencia. La regla es absoluta: el servidor define cuando se abren y cierran los lotes. El cliente muestra esa informacion.

Cierre de Lotes en el Lado del Servidor

El cierre del lote debe ser activado por un trabajo programado del lado del servidor, no por la marca de tiempo de la ultima puja ni por un temporizador del lado del cliente que llega a cero. Utilizamos un trabajador en segundo plano (que se ejecuta en un proceso dedicado o una funcion cloud programada) que consulta los lotes que entran en su ventana de cierre, transiciona su estado, activa la determinacion del ganador y despacha los eventos de liquidacion. Este trabajador debe ser idempotente — si se ejecuta dos veces debido a un fallo y reinicio, no debe cerrar un lote dos veces ni crear registros de liquidacion duplicados.

Sincronizacion de Reloj

Para propositos de visualizacion, los clientes necesitan saber la hora actual del servidor para renderizar cuentas regresivas precisas. Exponemos un endpoint /api/time que devuelve la marca de tiempo UTC actual e incluimos una marca de tiempo del servidor firmada en cada evento de puja WebSocket. Los clientes pueden calcular la diferencia entre su reloj local y la hora del servidor al conectarse y aplicar ese desplazamiento a todos los calculos de cuenta regresiva. Esto evita la deriva cosmetica — donde la cuenta regresiva de un pujador muestra "2 segundos" cuando el servidor ya ha cerrado el lote — que, incluso cuando no tiene efecto funcional, crea problemas de confianza y tickets de soporte.

Sistema de Notificaciones

Las plataformas de subastas generan un volumen muy alto de notificaciones sensibles al tiempo: alertas de superar la puja, recordatorios de apertura de lote, advertencias de cierre de lote, notificaciones de ganador, solicitudes de pago y confirmaciones de liquidacion al vendedor. El sistema de notificaciones se subestima con frecuencia tanto en terminos de diseno como de infraestructura.

Canales de Notificacion

La mayoria de las plataformas de subastas necesitan como minimo:

• Notificaciones en tiempo real en la aplicacion (WebSocket push a clientes conectados)
• Notificaciones por correo electronico (para usuarios que no estan actualmente en la plataforma)
• Notificaciones por SMS (para eventos de alto valor o criticos en el tiempo — alertas de puja superada, cierre de lote)
• Notificaciones push (para clientes moviles)

Volumen y Limitacion

Cuando un lote cierra, cada pujador superado recibe una notificacion de "no ganaste" simultaneamente. Para un lote popular con 200 pujadores, eso son 199 correos electronicos, 199 mensajes SMS (si estan habilitados) y 199 notificaciones push en un solo momento. Multiplica por 50 lotes cerrando en la misma ventana de 5 minutos y tienes 9,950 mensajes para despachar en minutos. Los proveedores de correo electronico tienen limites de tasa. Las puertas de enlace SMS tienen limites de rendimiento. Los servicios de notificaciones push tienen sus propios comportamientos de cola.

El sistema de notificaciones debe estar respaldado por una cola, con trabajadores separados para cada canal, logica de reintento con retroceso exponencial y monitoreo de la profundidad de la cola. Tipicamente usamos BullMQ (respaldado por Redis) para la cola de trabajos, con colas separadas para cada canal de notificacion y niveles de prioridad que garantizan que las notificaciones de ganador se despachen antes que las alertas masivas de puja superada.

---

Arquitectura Recomendada

Monolit vs. Microservicios

La conversacion sobre microservicios es inevitable en cualquier discusion de arquitectura tecnica en 2025. Nuestra posicion honesta: para casi todas las plataformas de subastas en sus primeros 18-24 meses, un monolito modular bien estructurado es la opcion correcta.

He aqui por que. Los microservicios introducen una complejidad operacional real: rastreo distribuido, descubrimiento de servicios, autenticacion entre servicios, latencia de red entre componentes y pipelines de despliegue independientes para cada servicio. Estos son costos que vale la pena pagar cuando tienes un equipo grande, alto trafico y limites de servicio bien comprendidos. En una plataforma de subastas en primera version con un equipo de cuatro a diez ingenieros, estos costos son casi siempre mas altos que los problemas que se supone que deben resolver.

Nuestra arquitectura inicial recomendada es un monolito modular con limites de dominio internos claros:

• bidding — el motor de pujas, validacion de pujas, manejo de condiciones de carrera
• lots — catalogo de lotes, maquina de estado, gestion del temporizador
• users — autenticacion, estado KYC, perfiles de comprador/vendedor
• notifications — plantillas de notificacion, enrutamiento de canales, trabajadores de despacho
• payments — autorizacion de pago, captura, liquidacion, facturacion
• admin — herramientas internas, gestion de subastas, informes

Cada modulo tiene sus propios modelos, servicios y controladores. La comunicacion entre modulos ocurre a traves de interfaces internas bien definidas — no consultas directas a la base de datos a traves de los limites del dominio. Cuando y si necesitas extraer un servicio (el motor de pujas es el candidato mas comun), los limites ya estaran en su lugar.

Patrones Orientados a Eventos

El dominio de pujas es naturalmente orientado a eventos. Se realiza una puja → evento bid.submitted. La puja se valida y acepta → evento bid.accepted. El temporizador del lote expira → evento lot.closing. Se determina el ganador → evento lot.won. Estos eventos son los desencadenadores del comportamiento posterior: despacho de notificaciones, inicio de pago, actualizaciones del panel del vendedor, entradas del registro de auditoria.

Implementamos esto con un bus de eventos interno para el monolito (sincrono en proceso para mayor velocidad, usando algo como EventEmitter2 o un patron observador simple) y un bus de eventos externo (Redis Streams o una cola de mensajes ligera) para todo lo que necesita durabilidad — eventos de pago, determinacion de ganador, confirmaciones de liquidacion. A medida que la plataforma crece y se extraen servicios, el bus interno transiciona al externo.

Consideraciones de Diseno de Base de Datos

El esquema de base de datos de subastas es mas complejo que un esquema estandar de comercio electronico. Decisiones clave de diseno:

• Lotes y pujas como tablas separadas con una relacion de clave foranea — nunca almacenes la puja mas alta actual como una columna en el registro del lote sin un mecanismo para garantizar la consistencia con la tabla de pujas
• Eliminaciones suaves en todo momento — los registros de subastas son registros financieros; nada se elimina definitivamente
• Particionar pujas por venta o periodo de tiempo — una plataforma popular puede acumular decenas de millones de registros de pujas; el particionado mantiene predecible el rendimiento de las consultas
• Bloqueo a nivel de fila en escrituras de lote — SELECT FOR UPDATE de PostgreSQL evita escrituras concurrentes en el mismo registro de lote sin la solucion Redis a nivel de aplicacion

---

Recomendaciones de Stack Tecnologico

Basandonos en nuestra experiencia construyendo y manteniendo plataformas de subastas en produccion, nuestro stack recomendado actual es:

Capa	Tecnologia	Razonamiento
Frontend	Next.js (React)	SSR para SEO del catalogo, React para UI de pujas en tiempo real
Estilos	Tailwind CSS	Desarrollo rapido, tokens de diseno consistentes
Cliente en tiempo real	Socket.io client	Reconexion automatica, soporte de salas
Backend	Node.js (TypeScript)	Mismo lenguaje en todo el stack, excelente ecosistema WebSocket
API REST/GraphQL	Express o Fastify	Probado, bien comprendido, facil de instrumentar
Base de datos principal	PostgreSQL	Cumplimiento ACID, bloqueo a nivel de fila, solida comunidad
Cache / estado de pujas	Redis	Scripts Lua atomicos, pub/sub, cola de trabajos (BullMQ)
Servidor en tiempo real	Socket.io	Salas, namespaces, adaptador Redis para multiples instancias
Colas de trabajos	BullMQ	Respaldado por Redis, logica de reintento, priorizacion de trabajos
Almacenamiento de medios	AWS S3 / Cloudflare R2	Escalable, listo para CDN, URLs de carga prefirmadas
Procesamiento de imagenes	Sharp / AWS Lambda	Generacion de miniaturas, conversion WebP
Busqueda	Busqueda de texto completo PostgreSQL o Typesense	Busqueda de texto completo en el catalogo de lotes
Correo electronico	SendGrid / Postmark	Correo electronico transaccional con seguimiento de entrega
SMS	Twilio	Notificaciones SMS y WhatsApp
Infraestructura	AWS (ECS/EC2) o Render	Contenedores gestionados, escalado automatico
CI/CD	GitHub Actions	Pipelines automatizados de prueba y despliegue
Monitoreo	Datadog o Grafana Cloud	APM, seguimiento de errores, monitoreo de colas

¿Por que no Python? Python es una excelente opcion para backends de subastas — Django tiene un solido historial en el desarrollo de marketplaces, y FastAPI maneja bien las cargas de trabajo asincronas. Optamos por Node.js por defecto porque comparte lenguaje con el frontend, simplificando la organizacion del equipo y el intercambio de conocimientos. Si la fortaleza de tu equipo es Python, con gusto construimos sobre esa base.

¿Por que no MongoDB? Los requisitos de consistencia del motor de pujas — transacciones entre registros relacionados, bloqueo a nivel de fila, garantias ACID — son donde las bases de datos relacionales superan genuinamente a los almacenes de documentos. MongoDB ha mejorado significativamente su soporte de transacciones, pero PostgreSQL sigue siendo la opcion mas natural para el modelo de datos financieros de una plataforma de subastas.

---

Lista de Verificacion de Funcionalidades Clave

Una plataforma de subastas lista para produccion requiere un conjunto de funcionalidades mas amplio del que la mayoria de los ejercicios de alcance inicial contemplan. Aqui esta la lista completa con la que trabajamos:

Experiencia del Pujador

• Registro del pujador con verificacion de correo electronico
• Flujo de verificacion KYC/identidad (proveedor externo integrado)
• Requisito de deposito o tarjeta registrada antes de pujar
• Catalogo de lotes con filtrado, ordenamiento y busqueda
• Paginas de lote individual con galeria de medios completa y detalles del lote
• Lista de seguimiento / guardar lotes para mas tarde
• Sala de pujas en vivo con actualizaciones de puja en tiempo real
• Puja por poder (puja automatica): el pujador establece un maximo, el sistema puja en su nombre hasta ese importe
• Indicador de estado del precio de reserva (cumplido / aun no cumplido)
• Opcion de compra inmediata (donde aplique)
• Notificaciones de puja superada (en la aplicacion, correo electronico, SMS)
• Cuenta regresiva de cierre del lote con indicadores de extension de cierre suave
• Generacion de factura post-subasta y pago
• Historial de pedidos e historial de lotes ganados
• Panel del pujador con lotes proximos, pujas activas, lotes ganados, estado de pago

Experiencia del Vendedor/Consignador

• Registro e incorporacion del vendedor
• Formulario de envio de lote (titulo, descripcion, imagenes, precio de reserva, precio inicial)
• Flujo de aprobacion de lote (pendiente de revision del administrador)
• Panel del vendedor con datos de rendimiento del lote (vistas, pujas, precio final)
• Notificaciones de liquidacion post-venta
• Procesamiento y historial de pagos

Panel de la Casa de Subastas / Administrador

• Gestion de ventas (crear, programar, cerrar ventas en subasta)
• Gestion de lotes (aprobar, editar, retirar, volver a listar)
• Gestion de pujadores (aprobar, suspender, revisar estado KYC)
• Panel de control de venta en vivo (para simulcast: aceptar/rechazar pujas en linea, controlar la secuencia de lotes)
• Historial de pujas y registro de auditoria por lote
• Gestion del precio de reserva
• Gestion de liquidacion (marcar lotes como pagados, iniciar pagos)
• Informes (totales de venta, primas del comprador, ingresos netos del vendedor, tasa de no vendidos)
• Exportacion de reconciliacion financiera (CSV para contabilidad)

Plataforma / Infraestructura

• Soporte multi-venta (ejecutar multiples eventos de subasta concurrentes)
• Soporte de temas de marca blanca
• API para integraciones de terceros
• Web responsive para movil (o aplicaciones moviles nativas)
• Medios entregados por CDN
• Monitoreo y alertas en tiempo real

---

Arquitectura de Pago y Liquidacion

Los pagos en subastas son fundamentalmente diferentes de los pagos estandar en comercio electronico, y tratarlos de la misma manera es uno de los errores mas comunes que vemos.

El Patron de Autorizacion-Retencion-Captura

En el comercio electronico estandar, el pago se captura en el momento del pago. En la mayoria de los formatos de subasta, no se conoce el precio final en el momento de la puja — e incluso cuando se conoce (en el caso de la puja por poder al cierre del lote), puede que no se quiera capturar el pago hasta que se confirme la liquidacion.

El patron correcto para la mayoria de las plataformas de subastas es:

1. Retencion de pre-autorizacion en el registro o antes de pujar en un lote — una autorizacion de tarjeta por un importe de deposito (tipicamente 250–2.000 € dependiendo de la categoria del lote) para verificar el metodo de pago y demostrar seriedad financiera
2. Determinacion del ganador — cuando un lote cierra, el sistema identifica al pujador ganador y el precio final
3. Generacion de factura — se crea la factura, incluyendo el precio de martillo mas la prima del comprador mas los impuestos aplicables
4. Captura del pago — se solicita al pujador ganador (o se le cobra automaticamente) el importe total de la factura, separado del deposito de registro

La autorizacion del deposito de registro generalmente se libera despues de que la subasta cierra para los pujadores no ganadores. Para los pujadores ganadores, el deposito puede acreditarse contra el total de la factura.

Liquidacion Post-Subasta

Para la mayoria de los clientes de casas de subastas, el ciclo de liquidacion es:

1. El pujador ganador paga la factura (tipicamente dentro de las 24-72 horas del cierre de la subasta)
2. La plataforma o la casa de subastas confirma la recepcion de fondos compensados
3. El comprador recoge o organiza la entrega del lote
4. Se inicia el pago al vendedor (tipicamente 14-21 dias despues del cierre de la subasta, menos comision y honorarios de listado)

Cada paso debe rastrearse en tu maquina de estado de liquidacion. Las facturas impagas necesitan recordatorios automatizados y, despues de un periodo definido, escalacion al equipo administrativo. Los pagos al vendedor necesitan integrarse con tu mecanismo de pago elegido — Stripe Connect es la opcion mas comun para plataformas tipo marketplace donde la plataforma retiene fondos en transito.

Recomendaciones de Proveedores de Pago

Proveedor	Mejor Para	Notas
Stripe	Reino Unido, UE, EE.UU., la mayoria de los mercados	Mejor API, Stripe Connect para pagos del marketplace
PayPal	Mercados donde la confianza en PayPal es alta	Util como opcion complementaria
Braintree	Multidivisa, alto volumen	Propiedad de PayPal, solidas herramientas antifraude
GoCardless	Debito bancario Reino Unido/UE	Bueno para liquidacion de facturas grandes
Checkout.com	Alto volumen, empresarial	Tarifas competitivas a escala
Stripe + regional	Plataformas globales	Stripe como principal, proveedor regional como respaldo

Para plataformas que operan en los EAU o Arabia Saudita, tipicamente implementamos PayTabs o HyperPay junto con Stripe para cobertura de tarjetas locales.

---

KYC y Prevencion del Fraude

Las subastas atraen una proporcion desproporcionada de fraude de pago y fraude de identidad en relacion con el comercio electronico estandar, por una razon simple: la presion de tiempo de las pujas crea menos oportunidades para un escrutinio cuidadoso, y las plataformas de subastas historicamente tienen menos friccion que las transacciones bancarias. Los estafadores explotan ambos.

Por Que las Subastas Atraen el Fraude

Los patrones de fraude comunes que encontramos:

• Puja fantasma: un vendedor (o su asociado) realiza pujas artificiales para inflar el precio de martillo. Tecnicamente detectable mediante analisis de direcciones IP, huellas dactilares del dispositivo, analisis de patrones de puja y mapeo de relaciones entre cuentas de comprador y vendedor.
• Fraude de pago: un pujador ganador realiza una puja sin intencion de pagar, usando credenciales de tarjeta robadas para el deposito. El fraude se descubre en la captura, dias despues de la subasta.
• Fraude de identidad: creacion de multiples cuentas bajo identidades falsas para eludir limites de pujadores o suspensiones.
• Fraude del vendedor: vendedores que listan articulos que no poseen o que no coinciden con la descripcion, cobran fondos del comprador y desaparecen antes del cumplimiento.

Enfoques de Verificacion de Identidad

Nivel 1 — Solo verificacion de correo electronico: Apropiado solo para lotes de bajo valor y bajo riesgo. No proporciona ninguna prevencion de fraude significativa.

Nivel 2 — Tarjeta registrada con verificacion de direccion: Requiere una tarjeta de pago valida con direccion de facturacion coincidente. Proporciona friccion basica contra el fraude. Adecuado para plataformas de consumidores de nivel medio.

Nivel 3 — Verificacion de identificacion oficial: Integracion con un proveedor KYC (Onfido, Jumio, Veriff) para verificar un pasaporte o licencia de conducir y hacer coincidir con una selfie. Este es el estandar minimo para plataformas que tratan con lotes superiores a 1.000-2.000 € o que operan en sectores regulados.

Nivel 4 — KYC completo con escrutinio ALD: Verificacion de documentos mas escrutinio de listas de vigilancia contra bases de datos de PEP (Personas Expuestas Politicamente) y sanciones. Requerido para operadores del mercado de arte bajo las Regulaciones de Lavado de Dinero del Reino Unido y para plataformas con bases de compradores institucionales o de alto patrimonio neto.

Requisitos de Deposito

Requerir una retencion de pre-autorizacion antes de pujar es uno de los mecanismos de prevencion de fraude de mayor valor disponibles — no porque haga imposible el fraude, sino porque eleva dramaticamente el costo de intentarlo. Un estafador que necesita una tarjeta valida y verificable para depositar un deposito antes de pujar en cualquier lote enfrenta una barrera significativa.

Los umbrales de deposito deben escalonarse por categoria de valor del lote. Una plataforma que tiene lotes de 50 € a 50.000 € en la misma venta no debe requerir el mismo deposito de todos los pujadores — tanto restringe demasiado el acceso en el extremo inferior como desprotege en el extremo superior.

---

Errores Comunes que Vemos

No Manejar las Condiciones de Carrera

El error tecnicamente mas danino. Los equipos construyen el camino feliz — una puja, un pujador, funciona en las pruebas — y luego salen en vivo. Bajo carga real, con pujas simultaneas, descubren que la base de datos tiene dos registros que afirman ser la puja mas alta en el mismo lote. El intento de solucionar esto en produccion, mientras la subasta esta en vivo y los pujadores estan mirando, es exactamente tan doloroso como suena.

La solucion no es complicada. Requiere pensar en ello antes de comenzar a construir el motor de pujas, no despues de que la primera venta en vivo produzca un incidente de integridad de datos.

Confiar en los Temporizadores del Lado del Cliente

Hemos visto esto en todas las formas imaginables. Temporizadores de cuenta regresiva JavaScript que determinan cuando se deshabilita el boton de envio. Temporizadores de aplicaciones moviles que derivan porque el dispositivo entro en suspension. Temporizadores de pestanas del navegador que se pausan cuando la pestana esta en segundo plano. En cada caso, la plataforma permite (o deniega) pujas basandose en un temporizador que no es la fuente de verdad autoritativa.

El servidor cierra los lotes. El servidor acepta o rechaza pujas basandose en el estado del lote en el momento de la solicitud. El temporizador del cliente es una conveniencia de visualizacion. Estos deben tratarse como preocupaciones completamente separadas.

Subestimar la Carga de Notificaciones

Una plataforma con 500 pujadores registrados y 100 lotes en una venta despachara aproximadamente 50.000 notificaciones en las dos horas de una venta en vivo — alertas de puja superada, advertencias de cierre de lote, notificaciones de ganador, solicitudes de pago. Los equipos que enrutan todo esto a traves de una unica funcion de correo electronico sincrona descubren esto en el peor momento posible.

Las notificaciones deben disenarse como un sistema asincrono respaldado por cola desde el primer dia. La adaptacion posterior es dolorosa e implica reescribir el despacho de notificaciones durante un sistema de produccion en vivo.

Construir para Un Formato de Subasta y Adaptar Posteriormente

Un cliente llega necesitando una subasta online temporizada. El equipo construye exactamente eso — una plataforma de subasta temporizada, con suposiciones sobre visualizacion de precio unico, linea de tiempo de lote unica, sin recuento de pujadores en vivo, sin soporte de simulcast incorporado en el modelo de datos. Seis meses despues, el cliente quiere agregar capacidad de simulcast en vivo. El trabajo de adaptar esto a un sistema disenado en torno a suposiciones diferentes rutinariamente cuesta mas que construirlo correctamente desde el principio.

Entender que formatos de subasta planea ejecutar el cliente — ahora y en 18 meses — es un prerequisito para la arquitectura, no una reflexion tardia.

Almacenar los Maximos de Puja por Poder de Forma Visible

La puja por poder (puja automatica) requiere almacenar el importe maximo del pujador. Este importe debe estar cifrado en reposo y nunca exponerse a ninguna otra parte — incluido el personal de la casa de subastas. Hemos revisado plataformas donde los maximos de puja por poder eran visibles en el panel de administracion, dando al operador de la casa de subastas la capacidad de ver el techo de cada pujador antes de que la subasta cierre. Dependiendo de la jurisdiccion y las reglas de la plataforma, esto es una violacion significativa de la confianza y potencialmente una exposicion legal. Los maximos de puja por poder deben almacenarse cifrados, descifrarse solo por el motor de pujas en el momento de la colocacion de la puja y nunca aparecer en ninguna interfaz administrativa.

---

Como Construimos Plataformas de Subastas en Cyberbeak

Hemos construido plataformas de subastas y marketplaces desde principios fundamentales suficientes veces como para tener un proceso repetible — pero ningun cliente ha tenido requisitos identicos, y no fingimos lo contrario.

Nuestro Proceso

Descubrimiento y Arquitectura (semanas 1-3): Llevamos a cabo talleres estructurados para definir los formatos de subasta, los recorridos de comprador y vendedor, los requisitos de cumplimiento y el panorama de integracion. Producimos un documento de arquitectura tecnica, un borrador del modelo de datos y una especificacion de funcionalidades antes de escribir una linea de codigo. Este no es un paso burocratico — es la fase que previene los errores costosos descritos anteriormente.

Construccion de Fundamentos (semanas 4-10): Infraestructura central, autenticacion, integracion KYC, catalogo de lotes, motor de pujas y capa WebSocket en tiempo real. Construimos el motor de pujas primero y lo sometemos a pruebas de estres antes de construir la UI encima de el, porque la UI puede cambiarse facilmente y el motor de pujas no.

Construccion de Funcionalidades (semanas 11-16): Paneles de comprador y vendedor, sistema de notificaciones, integracion de pagos, flujos de trabajo de liquidacion, panel de administracion, informes.

Integracion y Pruebas (semanas 15-18): Finalizacion de la integracion de terceros, pruebas de carga en el motor de pujas (apuntamos a 10x la concurrencia maxima proyectada antes del lanzamiento), revision de seguridad y auditoria de accesibilidad.

Piloto y Lanzamiento (semanas 18-20): Una venta piloto supervisada con un grupo limitado de pujadores antes del lanzamiento publico. Esto detecta los problemas operacionales que ninguna cantidad de pruebas revela — las preguntas de soporte, los casos extremos en el comportamiento real de los pujadores, los momentos en que el flujo de trabajo del subastador no coincide con las suposiciones del panel de administracion.

Plazos Tipicos

• Subasta online temporizada, formato unico, conjunto de funcionalidades estandar: 12-16 semanas
• Plataforma con capacidad en vivo/simulcast: 16-22 semanas
• Plataforma empresarial con multiples formatos de subasta, integraciones personalizadas, aplicaciones moviles: 24-36 semanas

Rango de Inversion

El desarrollo de plataformas de subastas se encuentra en un rango de inversion mas alto que el comercio electronico estandar, porque la complejidad tecnica es genuinamente mayor y el costo de equivocarse es mayor. Nuestros rangos tipicos de proyectos:

• Subasta online temporizada — alcance estandar: 80.000-130.000 £
• Plataforma con capacidad en vivo / simulcast: 130.000-180.000 £
• Plataforma multi-formato empresarial: 180.000-250.000 £+

Estas cifras reflejan un equipo de entrega con sede en el Reino Unido con ingenieros senior y un proceso de entrega completo. La entrega exclusivamente offshore puede reducir el costo pero tipicamente aumenta la sobrecarga de coordinacion y el riesgo en un dominio de problema donde la precision importa tanto como en este.

---

Preguntas Frecuentes

¿Podemos agregar capacidad de simulcast mas tarde si comenzamos con subastas online temporizadas?

Si, pero el costo de hacerlo correctamente depende en gran medida de como se arquitecto la plataforma inicial. Si el modelo de datos, la capa en tiempo real y el panel de administracion se construyeron con el futuro simulcast en mente — incluso si la funcionalidad no se implemento — la adicion es una extension, tipicamente 8-14 semanas de trabajo. Si la construccion inicial se optimizo puramente para subastas temporizadas sin consideracion de la funcionalidad en vivo, el trabajo se acerca mas a una reconstruccion parcial. Siempre recomendamos incluir la preparacion para simulcast en la arquitectura inicial incluso si la funcionalidad se implementa mas tarde.

¿Cuantos pujadores concurrentes puede manejar la plataforma?

Con escalado horizontal en la capa WebSocket (Socket.io con el adaptador Redis, desplegado detras de un balanceador de carga) y Redis manejando el estado de las pujas atomicamente, una plataforma bien construida puede manejar comodomente miles de pujadores conectados simultaneamente en cientos de lotes concurrentes. El factor limitante es casi siempre la capa de despacho de notificaciones, no el motor de pujas en si. Para plataformas con requisitos de concurrencia genuinamente extremos — decenas de miles de pujadores simultaneos — la arquitectura requiere una infraestructura mas especializada, que alcanzamos por separado.

¿Construyen aplicaciones moviles como parte de los proyectos de plataforma de subastas?

Construimos aplicaciones web responsive como estandar, que funcionan bien en navegadores moviles. Las aplicaciones dedicadas para iOS y Android estan disponibles como adicion al alcance del proyecto, tipicamente agregando 8-14 semanas y 30.000-60.000 £ a la inversion total. Para la mayoria de las plataformas de subastas, una experiencia web movil bien construida cubre el 85-90% de los casos de uso. Las aplicaciones nativas agregan valor donde se requieren notificaciones push, acceso a la camara para inspecciones de lotes o soporte offline profundo.

¿Que hay del cumplimiento — hay requisitos regulatorios especificos para las plataformas de subastas?

Si, y varian segun el sector y la geografia. Los operadores del mercado de arte en el Reino Unido estan regulados bajo las Regulaciones de Lavado de Dinero, Financiamiento del Terrorismo y Transferencia de Fondos de 2017 (en su forma enmendada), que imponen obligaciones ALD, requisitos KYC y deberes de reporte de transacciones. Las subastas de vehiculos tienen consideraciones de titulo y registro. Las subastas de alimentos y agricultura operan bajo regimenes de licencias especificos del sector. Las armas de fuego y ciertos productos basicos tienen implicaciones de control de exportaciones. Siempre recomendamos una revision de cumplimiento con un abogado especialista antes del lanzamiento de la plataforma, y construimos la infraestructura tecnica para respaldar cualquier postura de cumplimiento que produzca esa revision.

¿Puede la plataforma tener marca blanca para otras casas de subastas?

Si. Construimos plataformas con multiinquilino y marca blanca como capacidades arquitectonicas opcionales. Un modelo de marca blanca — donde multiples casas de subastas operan en la misma plataforma subyacente con su propia marca, catalogo y base de pujadores — requiere una arquitectura inicial mas compleja (aislamiento de inquilinos en la capa de datos, configuracion por inquilino, enrutamiento de subdominio o dominio personalizado), pero es un modelo comercialmente atractivo para los operadores de plataformas que desean servir a multiples clientes de casas de subastas. Hemos construido este modelo con exito y agrega aproximadamente un 30-40% al costo inicial de construccion a cambio de un modelo comercial significativamente mas escalable.

---

¿Listo para Construir?

Si estas evaluando la construccion de una plataforma de subastas — ya seas una casa de subastas establecida que se mueve en linea, una startup que entra en una vertical especializada o un operador que busca reemplazar un sistema heredado — nos gustaria hablar.

Somos selectivos sobre los proyectos que tomamos, porque las plataformas de subastas requieren una colaboracion profunda para construirse bien. La primera conversacion siempre es una discusion tecnica, no una llamada de ventas. Queremos entender tu formato de subasta, tu base de pujadores, tu entorno de cumplimiento y tu modelo comercial antes de decir cualquier cosa sobre plazos o costos.

Ponte en contacto con el equipo de Cyberbeak para iniciar esa conversacion.