3-Layer Transaction Lock
Utilizing Redis Redlock to serialize, followed by PostgreSQL row-level locks for transaction write-back.
SELECT status, winner_id FROM auctions WHERE id = $1 FOR UPDATE;Custom Web & Mobile App
Ebidzy: Real-Time Reverse Auction Platform
Developed a custom real-time reverse auction platform with NestJS, Next.js, Redis, and WebSockets, solving client-server countdown drift and concurrency-safe double-selling race conditions.
- Sector
- Custom Web & Mobile App
- Timeline
- 6 months
- Role
- Lead Systems Architect
- NestJS
- Next.js
- React Native
- Redis
- PostgreSQL
- WebSockets
- Stripe
- <5ms
- Distributed Lock Time
- 15K req/s
- Concurrency Throughput
Redis Redlock overhead during simultaneous Buy clicks
Zero deadlock transaction validation capacity
The problem
Resolving severe network clock drift in client-side countdowns and preventing race conditions and double-selling when thousands of users simultaneously trigger Buy Now clicks.
The solution
Engineered an NTP-style latency handshake syncing all client clocks to absolute server time and formulated a 3-layer concurrency-safe ordering pipeline.
Approach
How it was built.
01
State Isolation
Separated high-frequency bidding telemetry entirely into memory caches (Redis HASH) to shield primary database from excessive SQL write-locks.
02
NTP Clock Handshake
Constructed a WebSocket-based handshake estimating ping latency and adjusting client device timers to synchronize with server clock.
03
Deterministic Price Engine
Price drops appear random to participants but are generated deterministically server-side, guaranteeing the auction lands exactly on its minimum price at expiry. The client renders a projection of server state. It never computes a price of its own.
04
Tickets as the Bidding Primitive
Participation is gated by tiered ticket spend, from a single-ticket tap through to a 25-ticket drop, with auto-refill so a user never loses an auction to an empty balance mid-bid. The economics and the concurrency model were designed together, not bolted on.
Technical detail
The parts worth explaining.
What I took from it
- In-memory caches are critical for real-time states
- NTP handshakes are required for timing equity
Where it goes next
- Integrate localized multi-currency payout wallets via Stripe Connect
- Deploy real-time auction analytical heatmaps
Got a problem shaped like this?
If something here looks like what you're facing, tell me about it. The first conversation is an architecture discussion, not a sales call.