Architecture Recommendation

Hybrid is the winning shape

Recommendation v2: 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
Join live game session	Hybrid	Join live game 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.
Submit answer event	DynamoDB	Submit answer event is burst write traffic with a 35ms 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.
Update score atomically	Hybrid	Update score atomically 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.
Get top 100 leaderboard by region	DynamoDB	Get top 100 leaderboard by region is high read traffic with a 45ms 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.
Get top 100 global leaderboard	DynamoDB	Get top 100 global 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.
Get user session history by time range	Aurora DSQL	Get user session history by time range 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 disputed scoring event	Hybrid	Replay disputed scoring event 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.
Get user profile by userId	Aurora DSQL	Get user profile by userId 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.

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_mqzvgzya_dfe7af4f_rec_v2

Schema version

proj_mqzvgzya_dfe7af4f_schema_v2

Rules applied