ProdTwin Zero

Production-readiness simulator that turns app ideas into AWS Database schemas workload telemetry hot-key analysis and migration-ready architecture reports.

Comment

ProdTwin Zero cover

Inspiration

Frontend tools can generate useful interfaces in minutes, but backend data architecture still decides whether an app survives real production traffic. ProdTwin Zero was built for teams that want to move quickly without guessing their database model, access patterns, consistency boundaries, hot-key risks, and migration path.

What it does

ProdTwin Zero is a production-readiness simulator for app ideas. For the demo scenario, it models a Global Trivia Game targeting 1M users, 50k concurrent players, US + EU traffic, live sessions, score updates, and global/regional leaderboards.

The app generates:

  • Entities and access patterns for the product idea.
  • A Hybrid AWS Database recommendation.
  • Aurora schema versions and DSQL-compatible schema exports.
  • DynamoDB key designs, telemetry events, GSI risk queries, and hot-key metrics.
  • A workload simulator comparing bad, sharded, and regional rollup key strategies.
  • A migration diff planner and exportable production-readiness report.

Architecture diagram

How we built it

The app is a Next.js App Router application deployed on Vercel. The backend uses route handlers for projects, recommendations, simulations, exports, health checks, and cloud proof.

Aurora PostgreSQL is the primary backend for durable architecture facts: projects, app blueprints, blueprint entities, access patterns, database recommendations, schema versions, simulation run summaries, generated reports, and migration plans. The exported schema is also kept DSQL-compatible by avoiding foreign key constraints and using DSQL-style async index syntax in the DSQL export.

DynamoDB is the telemetry plane. It stores representative workload events, access-pattern metrics, hot-key samples, risk-indexed events, and replay timelines using a single-table design with PK/SK plus GSI1 and GSI2. The writer chunks BatchWrite requests, retries UnprocessedItems with exponential backoff, and adds an expiresAt TTL to control demo data cost.

AWS Database proof

Why these AWS Databases

AWS Database Proof

AWS Database Proof

Architecture Diagram

Aurora fits the relational architecture facts that need durable versioning, schema history, report generation, and structured joins. DynamoDB fits the high-throughput simulation stream where write patterns, hot partitions, and key design are the core product concern.

The key product moment is comparing:

  • Bad key: PK = GAME#gameId
  • Sharded key: PK = GAME#gameId#SHARD#n
  • Regional rollup: PK = REGION#region#GAME#gameId#SHARD#n

The simulator shows readiness improving from 43 to 93 while hot-key risk drops from 100 to 23.

What makes it production-minded

ProdTwin Zero is not just a static demo. The deployed app runs in strict cloud mode with REPOSITORY_MODE=aurora and REQUIRE_CLOUD_BACKEND=true. Production health endpoints verify Aurora, DynamoDB, and proof data. The app includes an end-to-end backend verifier that exercises health, project bundle loading, recommendation generation, all three simulations, report export, and cloud proof.

Vercel proof

Challenges

The hardest part was making a realistic workload simulator without pretending to run an expensive 1M-user load test. ProdTwin Zero writes representative sample events and extrapolates WCU/RCU, hot-key concentration, consistency risk, and shard pressure from the declared scale target.

Another challenge was making the database layer real enough for judging. Aurora is now the primary backend for core state, and DynamoDB is not a silent best-effort write path: cloud mode fails if required database writes fail.

Accomplishments

  • Built a full-stack Vercel + AWS Database app with a complete Landing -> Dashboard -> Canvas -> Architecture -> Simulation -> Export flow.
  • Implemented a rules-based architecture recommender with traceable database decisions.
  • Added Aurora-backed durable project, schema, recommendation, simulation, report, and migration data.
  • Added DynamoDB-backed telemetry, hot-key metrics, TTL, GSI queries, and BatchWrite retry handling.
  • Added AWS Proof Panel, DSQL-compatible schema export, migration diff, cost/reliability matrix, route snippets, and a production-readiness report.
  • Verified production with Aurora and DynamoDB connected.

What we learned

A database recommendation is much more convincing when it is tied to concrete access patterns, key design, telemetry, and migration steps. The simulator made it clear that choosing DynamoDB or Aurora is less important than making the read/write shape and consistency boundaries explicit.

What's next

More app templates, AWS cost estimation, Terraform/CDK export, CI integration, and GitHub PR comments that flag database architecture risks before merge.

Links and proof

Built With

  • aurora-dsql-compatible-schema
  • aurora-postgresql
  • aws-sdk
  • dynamodb
  • lucide-icons
  • next.js
  • postgresql
  • react
  • recharts
  • tailwind-css
  • typescript
  • vercel
Share this project:

Updates