Architecture Recommendation

Hybrid is the winning shape

Recommendation v7: Recommended Hybrid architecture: Aurora DSQL stores project metadata, access-pattern registry, schema versions, recommendations, and simulation summaries; DynamoDB stores workload telemetry, answer events, hot-key samples, and event replay timelines.

Run Simulation

Aurora First

72/100

Strong transactions, relational lineage, SQL reporting, and versioned architecture facts.

Risk: High-frequency answer events and leaderboard writes can become expensive and harder to partition deliberately.

Dynamodb First

78/100

Low-latency event writes, leaderboard reads, telemetry timelines, and hot-key analysis.

Risk: Transactional score settlement, schema versioning, and ad-hoc support queries become unnatural.

Hybrid

94/100

Aurora DSQL owns the architecture facts; DynamoDB owns the simulation event stream and hot-key workload.

Risk: More components to explain, monitor, and operate, but the boundaries match the workload.

Cost and reliability matrix

Strategy	Performance	Reliability	Cost	Consistency	Complexity	Reason
Aurora-first	72	88	61	94	70	Great relational lineage, but burst event writes stress the SQL path.
DynamoDB-first	91	84	78	68	76	Excellent event throughput, weaker for transactional review and schema history.
Hybrid	93	90	82	88	81	Aurora owns facts and versions; DynamoDB owns telemetry and hot-key workloads.

Access pattern mapping

Pattern	Database	Rationale	Why not Aurora	Why not DynamoDB
Update score	Hybrid	Update score crosses event replay and authoritative settlement, so Aurora DSQL should own the facts while DynamoDB carries the high-frequency stream.	A single relational write path would absorb burst telemetry and leaderboard fan-out that should be modeled around partition-key distribution.	Pure DynamoDB would make versioned schema history, transactional review, and ad-hoc support queries harder to govern.
Read regional leaderboard	DynamoDB	Read regional leaderboard is high read traffic with a 60ms target, so it needs access-pattern-first keys and elastic event throughput.	A single relational write path would absorb burst telemetry and leaderboard fan-out that should be modeled around partition-key distribution.	DynamoDB is the primary fit for this access pattern.
Read global leaderboard	DynamoDB	Read global leaderboard is burst read traffic with a 80ms target, so it needs access-pattern-first keys and elastic event throughput.	A single relational write path would absorb burst telemetry and leaderboard fan-out that should be modeled around partition-key distribution.	DynamoDB is the primary fit for this access pattern.
Join live session	Hybrid	Join live session crosses event replay and authoritative settlement, so Aurora DSQL should own the facts while DynamoDB carries the high-frequency stream.	A single relational write path would absorb burst telemetry and leaderboard fan-out that should be modeled around partition-key distribution.	Pure DynamoDB would make versioned schema history, transactional review, and ad-hoc support queries harder to govern.
Read user profile	Aurora DSQL	Read user profile needs relational facts, versioning, and strong query semantics more than raw event throughput.	Aurora DSQL is the primary fit for this access pattern.	Pure DynamoDB would make versioned schema history, transactional review, and ad-hoc support queries harder to govern.
Replay session history	Hybrid	Replay session history crosses event replay and authoritative settlement, so Aurora DSQL should own the facts while DynamoDB carries the high-frequency stream.	A single relational write path would absorb burst telemetry and leaderboard fan-out that should be modeled around partition-key distribution.	Pure DynamoDB would make versioned schema history, transactional review, and ad-hoc support queries harder to govern.
Submit answer event	DynamoDB	Submit answer event is burst write traffic with a 50ms target, so it needs access-pattern-first keys and elastic event throughput.	A single relational write path would absorb burst telemetry and leaderboard fan-out that should be modeled around partition-key distribution.	DynamoDB is the primary fit for this access pattern.

Architecture warnings

Single game partition can saturate during live rounds

critical

If answer events use PK = GAME#gameId, a 50k concurrent live game can concentrate thousands of writes per second on one logical key.

Add write sharding with GAME#gameId#SHARD#0..15 and replay by shard when rebuilding a round.

Global leaderboard should not be a single write target

high

A global top-100 materialization is read-friendly, but writing every score into LEADERBOARD#GLOBAL creates a hot aggregation point.

Maintain regional leaderboards with bucketed keys, then publish an async global projection.

Cross-continent strong writes need regional ownership boundaries

high

US + EU traffic with strong score settlement should avoid pretending one global relational write domain has no topology tradeoffs.

Use regional data domains for live play, then reconcile score facts and report projections through Aurora DSQL schema versions.

Representative samples should be extrapolated to protect cloud cost

moderate

The simulator should write hundreds or thousands of telemetry rows, then model the 1M-user case mathematically instead of generating full production load.

Cap each run at 5,000 sample events and calculate peak WCU/RCU from access-pattern frequency and key cardinality.

Versioned outputs

Recommendation

proj_global_trivia_rec_v7

Schema version

proj_global_trivia_schema_v7

Rules applied