Skip to main content
Architecture & Backend · 7 min

Real-Time Auto-Bidding Architecture: Execution in the Final 5 Seconds with .NET and Laravel

How to build an auction system that ingests 300,000+ public lots and fires automated bids within the final 5 seconds without database locks or concurrency crashes.

Pablo Fesa
Pablo Fesa Software Architect & Tech Lead

When an institutional investor schedules an automated bid on a high-value real estate or asset auction, the technical margin for error is exactly zero.

On government platforms like the Spanish Official Gazette (BOE) or Social Security portals, bids submitted during closing minutes often trigger automatic dynamic extensions. However, in private liquidation environments, the critical execution window is compressed into the final 5 to 10 seconds. If your service encounters a database row lock, garbage collection freeze, or network latency spike, the bid misses the closing window and the client loses the asset.

This article details the decoupled architecture we engineered for Diario de Subastas, combining Laravel 11 for catalog ingestion and domain logic with a dedicated .NET microservice for real-time execution.

The Pitfall of Coupling Web Traffic to Time-Critical Execution

In the early lifecycle of a legaltech platform, the default instinct is often to rely on the existing web backend (PHP/Laravel with Redis queues and Horizon workers) to handle both user-facing traffic and scheduled bid execution.

That approach works reliably when handling a dozen lots per day. But when tracking thousands of concurrent listings with simultaneous closing deadlines at 18:00 sharp, scaling bottlenecks surface quickly:

  1. Connection pool exhaustion and transactional lockups: When hundreds of worker processes attempt to read and write against the same transactional tables simultaneously, row-level locks (SELECT ... FOR UPDATE) degrade the MySQL connection pool.
  2. Execution timing jitter: While modern PHP with OPcache delivers outstanding throughput for web APIs, firing high-precision timers exactly 5 seconds before lot termination requires a compiled runtime with low-overhead threading and flat memory consumption.

The Decoupled Architecture

To eliminate points of failure, we segregated control plane responsibilities from the execution plane:

[Mass Ingestion: 25+ Scrapers] ──► [Laravel 11: Catalog & API]
                                            │
                                            ▼
                               [Persistent Queue Redis / DB]
                                            │
                                            ▼
                             ┌──────────────────────────────┐
                             │    Autonomous .NET Worker    │
                             │    - High-precision timers   │
                             │    - Pre-warmed HTTP sockets │
                             │    - Extension listener      │
                             └──────────────┬───────────────┘
                                            │
                                            ▼
                             [Official Portals / BOE API]

1. Control Plane in Laravel 11

  • Parallel ingestion pipelines: 55 Artisan scheduled commands coordinate distributed scrapers that ingest and normalize 25+ feeds in under 60 minutes.
  • Domain integrity: 88 domain models normalize cadastral references, court deposits, and judicial case statuses.
  • Pre-authorization checks: User escrow balances, mandate signatures, and bid caps are fully validated before scheduling.

2. Real-Time Execution Plane in .NET

  • Pre-warmed memory state: 60 seconds before lot closing, the .NET runner preloads authentication tokens, signed payloads, and connection state.
  • Pre-warmed HTTP sockets: TLS handshakes and socket negotiations are completed ahead of time, eliminating connection latency at T-5 seconds.
  • Reactive deadline monitoring: If a competing bid extends the closing window by two minutes, the worker adjusts its execution timer reactively without re-enqueuing heavy jobs.

Three Key Design Principles

  1. Strict request idempotency: In official auctions, accidental duplicate bids could commit double capital. Every submission generates a cryptographic idempotency token derived from auction ID, authorized amount, and signed timestamp.
  2. Network failure isolation: If an external target portal experiences temporary downtime or severe latency, the worker records packet-level audit traces proving the outage was upstream and protecting client liability.
  3. Out-of-band telemetry: Metrics and execution logs stream directly into memory queues and time-series backends, completely avoiding synchronous disk writes that could compete with active transactions.

Production Results

Since deploying this architecture, the platform has processed over 300,000 public and private auctions, maintaining an unbroken track record of zero failed scheduled bids.

The engineering takeaway: Choose the right tool for each boundary. Laravel is unrivaled for modeling complex business logic, REST APIs, and administrative control panels with speed; compiled runtimes like .NET or Rust are the natural choice when guaranteed execution timing in the final seconds decides the outcome.

Topics: #Laravel #.NET #Distributed Systems #Performance #MySQL
Continue Reading

Related Articles

Looking to architect resilient systems without budget overruns?

Book a 15-minute diagnostic session with Pablo to audit your bottlenecks and map out a clear technical path.