DEV Community

Cover image for Traffic vs Truth: Building a Global Auction Platform with DynamoDB and Aurora DSQL
Apurba Singh
Apurba Singh

Posted on

Traffic vs Truth: Building a Global Auction Platform with DynamoDB and Aurora DSQL

#h0hackathon #aws #dynamodb #nextjs

This article was created as part of my submission to the H0: Hack the Zero Stack with Vercel v0 and AWS Databases Hackathon.

The Core Philosophy

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.

The Problem

Imagine a global advertising exchange.

us-east-1        → $5.20
eu-west-1        → $5.30
ap-southeast-1   → $5.40
sa-east-1        → $5.35
Enter fullscreen mode Exit fullscreen mode

Thousands of bids arrive.

Most are temporary.

Only one becomes authoritative.

Winner = ap-southeast-1
Amount = $5.40
Enter fullscreen mode Exit fullscreen mode

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

The question became:

Should all 10,000 bids pay the same coordination cost as the single winning settlement?

My answer was no.

Architecture Overview 

Transient Bid Traffic
        ↓
     DynamoDB
        ↓
 Bid Evaluation
        ↓
 Authoritative Outcome
        ↓
   Aurora DSQL
        ↓
 OCC + Full Jitter
        ↓
 Financial Truth
        ↓
 Observability Layer
Enter fullscreen mode Exit fullscreen mode

The architecture follows one rule:

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

Why DynamoDB?

DynamoDB became the ingestion layer.

The platform stores bid events using a single-table design.

PK = SLOT#<slotId>
SK = REGION#<region>#BID#<bidId>
Enter fullscreen mode Exit fullscreen mode

Example:

await dynamodb.send(
  new PutCommand({
    TableName: "bid_events",
    Item: {
      PK: `SLOT#${slotId}`,
      SK: `REGION#${region}#BID#${bidId}`,
      bidAmount,
      latencyMs,
      qualityScore,
      timestamp: new Date().toISOString(),
      ttl: expiryTime,
    },
  })
);
Enter fullscreen mode Exit fullscreen mode

This allows:

  • High-throughput writes
  • Regional traffic aggregation
  • Hot slot detection
  • TTL cleanup
  • Analytics without joins

DynamoDB acts as a high-speed ingestion buffer.

Its job is not to determine truth.

Its job is to absorb traffic.

Why Aurora DSQL?

Eventually an auction closes.

The data is no longer traffic.

It becomes truth.

Aurora DSQL stores the authoritative state of the platform.

CREATE TABLE settlements (
    settlement_id UUID PRIMARY KEY,
    slot_id UUID NOT NULL,
    winner_account_id UUID NOT NULL,
    winning_bid NUMERIC(18,4),
    settled_at TIMESTAMPTZ
);
Enter fullscreen mode Exit fullscreen mode

Other core tables include:

enterprise_accounts
ad_slots
ad_bids
settlements
financial_ledger
conflict_events
simulation_runs
Enter fullscreen mode Exit fullscreen mode

These represent:

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

Only events that become business truth cross this boundary.

Why Vercel and Next.js?

The database architecture was the primary focus, but I also wanted to explore how globally distributed application runtimes interact with globally distributed databases.

Quant Edge Exchange was built using Next.js and deployed on Vercel.

The frontend dashboards, simulation engine, ingestion analytics, settlement telemetry, and ledger monitoring all run through server-side API routes.

One challenge was avoiding database initialization during build time.

Instead of creating clients globally, services are loaded lazily at runtime.

export async function getDsqlClient() {
  const { pool } = await import("./dsql-client");
  return pool;
}
Enter fullscreen mode Exit fullscreen mode

This allowed:

  • Successful Vercel builds
  • Runtime-only AWS connections
  • Clean separation of UI and infrastructure
  • Centralized database observability

The frontend visualizes the system.

The backend owns ingestion, settlement, conflict handling, and telemetry.

The Interesting Part: Settlement Contention

Ingestion is easy.

Settlement is where distributed systems become interesting.

Imagine two workers trying to settle the same auction.

Worker A
settle(slot_123)

Worker B
settle(slot_123)
Enter fullscreen mode Exit fullscreen mode

Without coordination, duplicate settlements become possible.

Aurora DSQL protects correctness through serializable transactions.

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

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

The platform implements:

  • Optimistic Concurrency Control (OCC)
  • Exponential Backoff
  • Full Jitter Retry

Example retry logic:

const delay =
  Math.random() *
  (BASE_DELAY * Math.pow(2, attempt));

await sleep(delay);
Enter fullscreen mode Exit fullscreen mode

Example execution:

Attempt #1
❌ Serialization Conflict

Attempt #2
❌ Serialization Conflict

Attempt #3
✅ Settlement Accepted
Enter fullscreen mode Exit fullscreen mode

This prevents synchronized retry storms while preserving transactional correctness.

Observability

Most demos stop after a successful write.

I wanted to expose what was happening underneath.

The platform includes:

  • Ingestion Analytics Dashboard
  • Settlement Monitoring
  • Financial Ledger Activity
  • Regional Traffic Distribution
  • Winning Region Analysis
  • OCC Conflict Telemetry

Example conflict metrics collected:

{
  conflicts: 12,
  retries: 31,
  resolved: 12,
  resolutionRate: 100
}
Enter fullscreen mode Exit fullscreen mode

The goal was to make contention visible instead of hiding it.

What I Learned

Building Quant Edge Exchange reinforced a lesson I had already seen in production systems.

The fastest architecture is not the one with the biggest database.

The fastest architecture is the one that assigns the correct consistency model to the correct workload.

DynamoDB and Aurora DSQL are often compared against each other.

After building this project, I think they are strongest when used together.

DynamoDB absorbs traffic.

Aurora DSQL protects truth.

Everything else becomes easier to reason about.

Try It Yourself

Demo:
https://quant-edge-exchange.vercel.app/

Devpost:
https://devpost.com/software/quant-edge-exchange

GitHub:
https://github.com/apurba-labs/quant-edge-exchange

Traffic is cheap.

Truth is expensive.

The architecture should know the difference.

Top comments (0)