Desenvolvimento de Plataforma de Leilão Empresarial

Usamos canais Supabase Realtime WebSocket com captura de alterações de dados PostgreSQL. Funciona assim: um lance chega, é validado na borda de rede via Supabase Edge Functions, escreve para PostgreSQL com garantias ACID completas e essa escrita confirmada dispara imediatamente uma transmissão para todos os assinantes através de conexões WebSocket persistentes. Não há camada de sincronização separada — nenhuma fila de mensagens entre o banco de dados e o fluxo WebSocket que possa variar ou descartar eventos. Esse acoplamento forte é exatamente aonde a maioria das arquiteturas de leilão perde latência. Eliminá-lo é como alcançamos consistentemente tempos de transmissão sub-200ms até sob carga real. E "carga real" importa aqui — é fácil atingir esses números em um ambiente de staging com 50 conexões simuladas. É um problema diferente quando você tem 3.000 licitantes ao vivo em um único leilão e alguém no lote acabou de ultrapassar $800.000.

Sim. E a forma que fazemos é um mecanismo de leilão composável com um core compartilhado — lances, lotes, usuários, registros de auditoria — e módulos específicos de vertical em camadas. Comportamento de temporizador para contagem regressiva de gado funciona diferente da lógica anti-sniping para arte fina, que funciona diferente das portas de elegibilidade exigidas para imóveis. Mas toda essa configuração vive no painel de admin, não no codebase. Então quando um casarão de leilão quer executar um formato de gala beneficente no próximo mês depois de executar vendas de propriedade o ano todo, eles configuram. Sem alterações de código, sem deployment, sem planejamento de sprint necessário. É o payoff prático de construir o mecanismo dessa forma — sua equipe de operações não é bloqueada por sua equipe de desenvolvimento toda vez que o negócio quer tentar algo ligeiramente diferente. Em mercados de leilão, flexibilidade de formato não é um luxo. É como você permanece competitivo entre verticais sem girar plataformas completamente separadas.

Sustentamos 10.000+ conexões WebSocket simultâneas em um único projeto Supabase sem tocar a infraestrutura. Esse é um número real de um evento real — não um teste de carga. A arquitetura escala horizontalmente através do pooling de conexões gerenciado Supabase e clustering WebSocket, então a maioria do crescimento é tratada sem intervenção. Mas para eventos onde sabemos que um pico está chegando — galas beneficentes importantes em Nova York, liquidações de portfólio imobiliário, vendas de propriedade de alto perfil — provisionamos infraestrutura dedicada com antecedência. Autoscaling é ótimo até não ser. Para um evento de leilão de $4M, "esperando que alcance" não é uma estratégia aceitável. O custo de pré-provisionar para um evento de tráfego alto conhecido é trivial comparado ao custo de uma experiência degradada quando 2.000 licitantes atingem a plataforma simultaneamente e o sistema começa a atrasar no momento exato errado.

Se um cliente se desconectar, ele se reconecta automaticamente e ressincroniza o estado de lance diretamente de PostgreSQL. E como o banco de dados é a fonte da verdade — não o fluxo WebSocket — nada é perdido. O fluxo é um mecanismo de entrega. Os dados vivem no banco de dados. Então uma desconexão de 10 segundos durante um leilão ao vivo significa o cliente volta e imediatamente alcança o estado atual. A UI mostra um indicador de status de conexão durante a janela de reconexão e qualquer tentativa de lance durante essa janela é enfileirada. Além — e isto é importante — agentes de lance automático continuam executando no lado do servidor independentemente do que está acontecendo com qualquer conexão de cliente individual. Então mesmo se o laptop de um licitante perder WiFi no pior momento possível, seu lance automático máximo ainda está sendo honrado. Esse é o tipo de confiabilidade que faz licitantes de alto valor confiar em uma plataforma o suficiente para definir limites de lance automático significativos em primeiro lugar.

Cada evento de lance escreve para um registro de auditoria somente append em PostgreSQL: timestamp, identidade de licitante, endereço IP, valor de lance, estado de leilão. Segurança em nível de linha bloqueia aquele registro após escrita — ninguém o modifica, nem mesmo sua própria equipe de admin. Esse registro é legalmente defensável, exporta limpo para submissão regulatória e realmente se manteve em procedimentos de disputa. Para imóveis e outros verticais de alto valor, adicionamos portas de verificação KYC/AML antes de qualquer licitante poder participar. Eles não veem preços de reserva, não enviam lances, até que a verificação de identidade seja compensada. Isso não é complexidade extra — é o que operador em mercados regulados realmente requer. E honestamente, casarões de leilão nesses verticais apreciam. Reduz o número de inscrições não-qualificadas poluindo seu pool de licitantes e dá a eles um processo defensável se uma venda alguma vez for desafiada pós-fechamento.

A plataforma core com um vertical vai ao vivo em 8-12 semanas. Cada vertical adicional leva 4-6 semanas a partir dali. O investimento varia de $75.000 para uma plataforma de vertical único até $250.000+ para sistemas empresariais multi-vertical que incluem recursos de IA, aplicativos móveis e integrações de terceiros. Mas aqui está o que importa praticamente: entregamos em fases, o que significa que você está executando leilões reais — com licitantes reais e receita real — antes que o escopo completo esteja concluído. Você não está esperando 6 meses por um grande lançamento. Você está ao vivo, você está aprendendo e você está gerando dados sobre o que realmente importa antes das decisões maiores de investimento serem feitas. Essa sequência muda o perfil de risco de todo o projeto. Você não está se comprometendo com $250.000 upfront em uma spec. Você está validando a plataforma em volume de leilão real antes das decisões de investimento maiores serem feitas.

Absolutamente. O frontend Next.js lida com tematização multi-tenant com domínios personalizados, logos, esquemas de cores e modelos de email configurados por casarão de leilão. Os dados de cada tenant são completamente isolados através de políticas de segurança em nível de linha PostgreSQL — não filtragem de nível de aplicação que pode ter casos extremos, mas isolamento forçado por banco de dados. Então o modelo plataforma-de-plataformas realmente funciona na prática: múltiplos casarões de leilão, múltiplas marcas, rodando independentemente em infraestrutura compartilhada, com nenhum deles ciente que os outros existem na mesma stack. Isso é o que torna este modelo economicamente interessante — você não está reconstruindo infraestrutura para cada novo casarão de leilão que você onboarda. Você está adicionando uma nova configuração de tenant. O custo marginal do décimo casarão de leilão em sua plataforma é uma fração do que o primeiro custou, e seu investimento em infraestrutura já está ganhando seu salário em cada vertical que você está executando.