High-frequency auction platform

A production-ready auction platform designed for high-concurrency bidding wars where fairness is non-negotiable. Built to handle bidders on a single item, the system guarantees that every winning bid is processed atomically and broadcasted with millisecond latency without ever crashing the browser.

View Source
High-frequency auction platform

The Problem

In high-frequency bidding, standard REST models fail. The core challenges included: * Race Conditions: Two users bidding the same amount simultaneously, leading to "stale" bids or incorrect winners. * Distributed Inconsistency: The risk of a database successfully saving a bid but failing to notify the UI, leaving users in the dark. * Frontend Performance: Updating a React UI on every single micro-event can saturate the main thread, causing the browser to freeze during intense bidding spikes.

The Solution

I engineered a resilient, event-driven architecture based on three architectural pillars: 1. Optimistic SQL Locking: Eliminated race conditions by moving concurrency checks into atomic SQL UPDATE queries. This guaranteed that only the first bid to hit the database at a specific price would ever succeed. 2. Transactional Outbox Pattern: Implemented a reliable event relay. By saving bids and notification events in a single DB transaction, I ensured that no "winning event" is ever lost—even if the API crashes mid-broadcast. 3. High-Performance UI Buffering: Developed a custom React hook that captures high-frequency WebSocket pulses into a mutable buffer, "flushing" them to the UI at a controlled 10fps. This decoupled data throughput from visual rendering, ensuring a silky-smooth experience under heavy load.

My Role

Lead Full-Stack & Systems Architect

Tech Stack

NestJSReactRedis Pub/SubPostgreSQLDockerk6

Key Decisions

  • 1

    REST for Writes, WS for Reads: Decided to use REST for bid placement to leverage HTTP headers for Idempotency Keys, ensuring network retries never result in duplicate bids, while reserving WebSockets strictly for efficient data streaming.

  • 2

    Redis Pub/Sub Backbone: Chose Redis as the messaging broker to allow the platform to scale horizontally. Adding more API nodes increases connection capacity without overloading the primary database.

  • 3

    Automated Performance Guardrails: Integrated k6 stress testing into the development workflow to mathematically prove that the system maintains p95 latency under 200ms with 100+ concurrent virtual users.

Screenshot Gallery

Screenshot