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
Thousands of bids arrive.
Most are temporary.
Only one becomes authoritative.
Winner = ap-southeast-1
Amount = $5.40
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
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>
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,
},
})
);
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
);
Other core tables include:
enterprise_accounts
ad_slots
ad_bids
settlements
financial_ledger
conflict_events
simulation_runs
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;
}
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)
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);
Example execution:
Attempt #1
❌ Serialization Conflict
Attempt #2
❌ Serialization Conflict
Attempt #3
✅ Settlement Accepted
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
}
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.
