Quant Edge Exchange

A million-scale global ad exchange simulator that separates high-velocity bid ingestion from globally consistent financial settlement using Amazon DynamoDB, Aurora DSQL, and Vercel.

Comment

Inspiration

Over the years I've worked on systems that experienced unpredictable traffic spikes, from consumer-facing platforms to real-time security monitoring systems.

One pattern kept appearing.

Distributed systems often treat every incoming event as if it deserves the same level of consistency, durability, and global coordination.

In reality, most events are temporary.

A bid is a perfect example.

Thousands of bids may arrive for the same advertising slot. Most are evaluated and discarded. Only one eventually becomes the winning settlement that affects a financial ledger.

This led to a simple design philosophy:

Traffic and truth are different data products.

Not every event deserves global consistency.

Quant Edge Exchange was built to explore what happens when we separate those responsibilities and allow each database to focus on the workload it handles best.

What it does

Quant Edge Exchange is a distributed ad auction and settlement simulation platform.

The system models how a global advertising exchange can process large volumes of bidding activity while maintaining correct financial settlement records.

The platform intentionally separates the lifecycle of an auction into two stages:

Transient Traffic

Incoming bids are treated as short-lived events.

us-east-1        → $5.20
eu-west-1        → $5.30
ap-southeast-1   → $5.40
sa-east-1        → $5.35

Hundreds or thousands of bids may be submitted for a single advertising opportunity.

Most of these events are temporary signals.

Financial Truth

Only one outcome eventually becomes authoritative:

Winner = ap-southeast-1
Amount = $5.40

The winning settlement becomes part of the financial ledger and must remain globally consistent.

The platform visualizes this transition through ingestion analytics, conflict telemetry, settlement monitoring, and financial ledger views.

How we built it

The architecture is based on a simple principle:

The cost of coordination should match the value of the data.

Architecture Overview

Transient Bid Traffic
        ↓
     DynamoDB
        ↓
 Bid Evaluation
        ↓
 Authoritative Outcome
        ↓
   Aurora DSQL
        ↓
 OCC + Jitter
        ↓
 Financial Truth
        ↓
 Observability Layer

Why Two Databases?

A common approach would be to push every event through the same database.

We intentionally avoided that design.

If 10,000 bids arrive for an auction and only one becomes the winning settlement, forcing all 10,000 events through globally coordinated transactions creates unnecessary coordination overhead.

Instead:

DynamoDB — Ingestion Layer

DynamoDB handles high-frequency bidding activity.

DynamoDB was selected because bid ingestion is append-heavy, regionally distributed, and optimized for throughput rather than global transactional coordination.

The ingestion schema uses a single-table design:

PK = SLOT#<slotId>
SK = REGION#<region>#BID#<bidId>

This allows:

  • Fast event ingestion
  • Regional traffic aggregation
  • Efficient slot-level analytics
  • Short-lived telemetry storage using TTL

DynamoDB acts as the platform's high-speed write buffer.

Aurora DSQL — Settlement Layer

Aurora DSQL is reserved for authoritative business records.

Aurora DSQL was selected because settlement records require globally consistent transactional guarantees while remaining available across distributed regions.

Tables include:

enterprise_accounts
ad_slots
ad_bids
settlements
financial_ledger
conflict_events
simulation_runs

These tables represent the final state of the system:

  • Winning bids
  • Settlement records
  • Account balances
  • Financial audit history
  • Conflict telemetry

Only events that become business truth cross this boundary.

Why Settlement Contention Matters

The most interesting part of the platform is not ingestion.

It is settlement.

Imagine an auction closes and two workers attempt to settle the same slot simultaneously.

Worker A
settle(slot_123)

Worker B
settle(slot_123)

Both workers believe they have valid state.

Without coordination, duplicate settlements could occur.

Aurora DSQL protects correctness through serializable transaction guarantees.

Under contention, one transaction may succeed while another encounters a serialization conflict.

Rather than treating this as an application failure, Quant Edge Exchange models contention as a normal distributed systems event.

The platform implements:

  • Optimistic Concurrency Control (OCC)
  • Exponential Backoff
  • Full Jitter Retry Logic
Attempt #1
❌ Serialization Conflict

Attempt #2
❌ Serialization Conflict

Attempt #3
✅ Settlement Accepted

Retry delay:

retryDelay =
random(0, base * 2^attempt)

This prevents synchronized retry storms while preserving transactional correctness.

The dashboard exposes conflict counts, retry depth, and resolution metrics so engineers can observe contention behavior directly.

Challenges we ran into

Aurora DSQL Compatibility

Aurora DSQL is not a traditional PostgreSQL deployment.

Several assumptions common in monolithic relational systems required adjustment, including schema initialization workflows, UUID generation strategies, and deployment automation patterns.

Modeling Contention

Creating realistic settlement conflicts required intentionally introducing competing settlement paths and building observability around retry behavior.

Production Deployment

Deploying a monorepo application to Vercel while integrating AWS SDKs, DynamoDB, Aurora DSQL, and OIDC-based authentication required significant runtime validation and deployment hardening.

Accomplishments that we're proud of

  • Built a hybrid database architecture based on workload characteristics rather than convenience.
  • Demonstrated separation between transient traffic and authoritative business records.
  • Implemented an observable OCC retry engine with conflict telemetry.
  • Designed a DynamoDB single-table ingestion model aligned with real access patterns.
  • Successfully deployed the platform using Vercel and AWS infrastructure.
  • Created operational dashboards that expose ingestion, settlement, and contention behavior.

What we learned

The most important lesson was that distributed systems become easier to reason about when events are classified by value.

Not every event deserves the same consistency guarantees.

Transient traffic and financial truth are fundamentally different workloads.

Once those workloads are separated, the architecture becomes simpler, more observable, and easier to scale.

We also gained a deeper understanding of Aurora DSQL's distributed transaction model, optimistic concurrency handling, and how DynamoDB and Aurora DSQL can complement each other rather than compete.

The project reinforced a simple lesson:

Distributed systems scale more effectively when coordination is applied only where business truth requires it.

What's next for Quant Edge Exchange

Future work includes:

  • Aurora DSQL Change Streams integration
  • DynamoDB Global Tables
  • EventBridge-driven settlement workflows
  • Multi-tenant auction isolation
  • Regional failover simulations
  • Advanced auction ranking models
  • Chaos testing for contention-heavy scenarios

The long-term goal is to continue exploring how distributed systems can balance throughput, coordination cost, and transactional correctness without forcing every workload through the same consistency model.

Built With

Share this project:

Updates