A gaming platform needs millisecond leaderboards for 2M daily players, relational inventory with ACID transactions and joins, plus petabyte-scale analytics over historical seasons. Single database cannot meet latency, consistency, and scale together. Which database selection fits access patterns and scalability?

The correct design aligns each access pattern with a purpose-built engine: DynamoDB delivers single-digit millisecond key-value writes and reads that scale horizontally for 2M daily leaderboard updates, Aurora provides relational ACID transactions, secondary indexes and SQL joins required for inventory integrity, and Redshift offers columnar MPP storage and parallel queries for petabyte-scale scans over historical seasons without impacting live traffic. By contrast using Aurora read replicas for petabyte analytics fails on analytic scalability because row-store replicas retain OLTP storage limits and lack columnar compression and MPP parallelism so large full-table scans contend and become cost-prohibitive. Using Aurora for both leaderboards and inventory fails on extreme write throughput and latency because even provisioned relational writers face connection, locking and partition limits under millions of concurrent sorted updates that a NoSQL key-value store absorbs elastically. Using DynamoDB transactions for relational inventory fails on relational semantics because despite transactional writes it has no native joins, foreign keys or ad-hoc SQL needed for inventory consistency checks. Exam caveat is to select services by latency, consistency and scan size rather than minimizing service count when the stem explicitly states tradeoffs cannot be met together. Practical check is to estimate peak writes per second, transaction join complexity and historical data volume with retention before sizing partitions, instance classes and warehouse concurrency.