Enterprise Auction Platform Development

Utilizamos canales WebSocket Supabase Realtime con captura de cambios de datos de PostgreSQL. Así es cómo funciona realmente: una oferta entra, se valida en el edge de la red vía Supabase Edge Functions, se escribe en PostgreSQL con garantías ACID completas, y esa escritura confirmada dispara inmediatamente una difusión a todos los suscriptores a través de conexiones WebSocket persistentes. No hay capa de sincronización separada — no hay cola de mensajes sentada entre la base de datos y el flujo de WebSocket que pueda desviarse o soltar eventos. Ese acoplamiento tight es exactamente donde la mayoría de arquitecturas de subastas sangran latencia. Eliminarlo es cómo consistentemente alcanzamos tiempos de difusión sub-200ms incluso bajo carga real. Y "carga real" importa aquí — es fácil golpear esos números en un ambiente de staging con 50 conexiones simuladas. Es un problema diferente cuando tienes 3,000 postores en vivo en una sola subasta y alguien en el lote acaba de cruzar $800,000.

Sí. Y la forma en que lo hacemos es un motor de subasta componible con un núcleo compartido — ofertas, lotes, usuarios, registros de auditoría — y módulos específicos de vertical en capas encima. El comportamiento del temporizador para una cuenta regresiva de ganado funciona diferente que la lógica anti-sniping para bellas artes, que funciona diferente que las puertas de elegibilidad requeridas para bienes raíces. Pero toda esa configuración vive en el panel de administración, no en el codebase. Entonces cuando una casa de subastas quiere ejecutar un formato de gala benéfica el próximo mes después de ejecutar ventas de herencia todo el año, lo configura. Sin cambios de código, sin deployment, sin planificación de sprint requerida. Ese es el beneficio práctico de construir el motor así — tu equipo de operaciones no está bloqueado por tu equipo de desarrollo cada vez que el negocio quiere intentar algo ligeramente diferente. En mercados de subastas, la flexibilidad de formato no es un lujo. Es cómo mantienes competitividad en verticales sin spin up de plataformas completamente separadas.

Hemos sostenido 10,000+ conexiones WebSocket concurrentes en un solo proyecto Supabase sin tocar infraestructura. Ese es un número real de un evento real — no una prueba de carga. La arquitectura escala horizontalmente a través de agrupación de conexiones administrada por Supabase y clustering de WebSocket, entonces la mayoría del crecimiento se maneja sin intervención. Pero para eventos donde sabemos que viene un pico — galas benéficas importantes en Nueva York, liquidaciones de cartera de bienes raíces, ventas de herencias de alto perfil — aprovisionamos infraestructura dedicada con anticipación. El autoscaling es excelente hasta que no. Para un evento de subasta de $4M, "esperando que se ponga al día" no es una estrategia aceptable. El costo de pre-aprovisionamiento para un evento de tráfico conocido-alto es trivial en comparación con el costo de una experiencia degradada cuando 2,000 postores golpean la plataforma simultáneamente y el sistema comienza a lagear en exactamente el momento incorrecto.

Si un cliente se desconecta, se reconecta automáticamente y resincroniza el estado de la oferta directamente desde PostgreSQL. Y porque la base de datos es la fuente de verdad — no el flujo de WebSocket — nada se pierde. El flujo es un mecanismo de entrega. Los datos viven en la base de datos. Entonces una desconexión de 10 segundos durante una subasta en vivo significa que el cliente vuelve e inmediatamente se pone al día con el estado actual. La UI muestra un indicador de estado de conexión durante la ventana de reconexión, y cualquier intento de oferta durante esa ventana se pone en cola. Además — y esto es importante — los agentes de autobid continúan ejecutándose del lado del servidor sin importar lo que esté sucediendo con cualquier conexión de cliente individual. Entonces incluso si la laptop de un postor pierde WiFi en el peor momento posible, su autobid máximo todavía se está honrando. Ese es el tipo de confiabilidad que hace que postores de alto valor confíen en una plataforma lo suficiente como para establecer límites de autobid significativos en primer lugar.

Cada evento de oferta se escribe en un registro de auditoría append-only en PostgreSQL: timestamp, identidad del postor, dirección IP, monto de oferta, estado de subasta. Seguridad a nivel de fila bloquea ese registro después de escritura — nadie lo modifica, ni siquiera tu propio equipo de administración. Ese registro es defendible legalmente, se exporta limpiamente para presentación regulatoria, y realmente se ha mantenido en procedimientos de disputa. Para bienes raíces y otras verticales de alto valor, agregamos puertas de verificación KYC/AML antes de que cualquier postor pueda participar. No ven precios de reserva, no envían ofertas, hasta que la verificación de identidad se aclare. Eso no es complejidad extra — es lo que operar en mercados regulados realmente requiere. Y honestamente, casas de subastas en esas verticales lo aprecian. Reduce el número de registros no calificados desordenando su grupo de postores y les da un proceso defendible si una venta alguna vez se cuestiona después del cierre.

La plataforma principal con una vertical se pone en vivo en 8-12 semanas. Cada vertical adicional toma 4-6 semanas desde ahí. El rango de inversión es de $75,000 para una plataforma de vertical única hasta $250,000+ para sistemas empresariales multi-vertical que incluyen características de IA, aplicaciones móviles e integraciones de terceros. Pero aquí está lo que importa prácticamente: entregamos por fases, lo que significa que estás ejecutando subastas reales — con postores reales e ingresos reales — antes de que el alcance completo se complete. No estás esperando 6 meses para un gran reveal. Estás en vivo, estás aprendiendo, y estás generando datos sobre lo que realmente importa antes de que se tomen decisiones de inversión más grandes. Esa secuenciación cambia el perfil de riesgo de todo el proyecto. No estás comprometiendo $250,000 por adelantado en una especificación. Estás validando la plataforma en volumen de subasta real antes de que se tomen las decisiones de inversión más grandes.

Absolutamente. El frontend de Next.js maneja tematización multi-tenant con dominios personalizados, logos, esquemas de color y plantillas de email configuradas por casa de subastas. Los datos de cada tenant están completamente aislados a través de políticas PostgreSQL row-level security — no filtrado a nivel de aplicación que puede tener casos extremos, pero aislamiento ejecutado por base de datos. Entonces el modelo de plataforma-de-plataformas realmente funciona en la práctica: múltiples casas de subastas, múltiples marcas, ejecutándose independientemente en infraestructura compartida, sin que ninguna esté consciente de que las otras existen en el mismo stack. Eso es lo que hace este modelo económicamente interesante — no estás reconstruyendo infraestructura para cada nueva casa de subastas que incorporas. Estás agregando una configuración de nuevo tenant. El costo marginal de la décima casa de subastas en tu plataforma es una fracción de lo que costó la primera, y tu inversión de infraestructura ya se está pagando en cada vertical que estás ejecutando.