Task 3.3: Determine high-performing database solutions.

• APut a DynamoDB Accelerator (DAX) cluster in front of the table and use a DAX client

  Correct

  DAX is an in-memory cache that is API-compatible with DynamoDB and cuts eventually consistent reads from milliseconds to microseconds with minimal changes.

• BAdd an Amazon ElastiCache cluster and write cache-aside logic around every read

  Incorrect

  ElastiCache can cache the profiles, but the developers would write and maintain the caching logic, which is more change than a drop-in client.

• CSwitch the table to on-demand capacity mode so that it scales with the read traffic

  Incorrect

  On-demand mode changes how throughput is provisioned and billed; reads still take single-digit milliseconds.

• DTurn the table into a global table with replica tables in two more AWS Regions

  Incorrect

  Global tables replicate data across Regions for multi-Region access and resilience; they do not bring reads down to microseconds.

Microsecond reads from DynamoDB with almost no code change is the reason DAX exists.

• AAmazon RDS for PostgreSQL with read replicas, adding each replica's endpoint to the app

  Incorrect

  Each RDS read replica is its own DB instance with its own endpoint, so the application must track replicas as they come and go.

• BAmazon RDS for PostgreSQL as a Multi-AZ DB instance deployment, reading from the standby

  Incorrect

  The standby in a Multi-AZ DB instance deployment cannot serve read traffic.

• CAmazon DynamoDB with eventually consistent reads served from a global secondary index

  Incorrect

  DynamoDB is a NoSQL key-value and document database, so moving to it means rewriting a PostgreSQL application.

• DAmazon Aurora PostgreSQL with Aurora Replicas, reading through the reader endpoint

  Correct

  The Aurora reader endpoint balances connections among all Aurora Replicas in the cluster, so replicas can be added or removed without app changes.

One endpoint that spreads reads over a changing set of replicas is Aurora's reader endpoint.

• ARaise the table's provisioned write capacity units until the throttling stops

  Incorrect

  Each partition has its own maximum of 1,000 write units per second. Extra table capacity does not lift that limit for one hot key.

• BAdd a global secondary index on the sale ID so the index takes some writes

  Incorrect

  An index is maintained in addition to the table; every write to the base table still lands on the same partition key.

• CAdd a random suffix to the partition key so writes spread across partitions

  Correct

  Write sharding appends a suffix so that writes for one logical key are spread over many partition key values.

• DSwitch the application's reads to eventually consistent reads to free capacity

  Incorrect

  Read consistency changes the cost of reads only. The throttled operations are writes.

Throttling with spare table capacity is the signature of a hot partition. Spread the key; do not add capacity.

• AAmazon ElastiCache for Memcached with every score stored under its own key

  Incorrect

  Memcached has no sorted sets and no replication, so it can neither rank players directly nor survive a node failure.

• BAmazon ElastiCache for Valkey with replication and a sorted set of scores

  Correct

  Valkey keeps a sorted set ranked in memory and supports replication with automatic failover, which fits a leaderboard.

• CAmazon RDS for MySQL with an index on the score column and read replicas

  Incorrect

  A disk-based relational database is noticeably slower than an in-memory store for this kind of constant ranking.

• DAmazon DynamoDB with a table scan sorted by score on every rank request

  Incorrect

  A Scan reads every item in the table, which is slow and costly for each rank lookup.

Leaderboards are a textbook use of in-memory sorted sets. Valkey or Redis OSS has them; Memcached does not.

• AAmazon Neptune, with the entities and relationships stored as a graph

  Correct

  Neptune is a graph database built to store and navigate highly connected data quickly, and fraud detection is one of its documented use cases.

• BAmazon DynamoDB, with a global secondary index for each relationship type

  Incorrect

  DynamoDB is a key-value and document store. Following many hops means many separate lookups assembled by the application.

• CAmazon Redshift, with the relationship tables distributed by account ID

  Incorrect

  Redshift is a data warehouse for analytical queries over large data sets, not for low-latency traversal of relationships per transaction.

• DAmazon RDS for PostgreSQL on a larger instance class, with read replicas for the queries

  Incorrect

  More capacity speeds up the same self-joins somewhat, but the data model, not the instance, makes multi-hop queries slow.

Multi-hop questions over relationships are what graph databases answer well. Relational and key-value models answer them with joins or repeated lookups.

• AAmazon DynamoDB, with the data access layer rewritten for the DynamoDB API

  Incorrect

  DynamoDB is serverless, but it does not accept CQL, so the data access code would have to be rewritten.

• BAmazon Keyspaces (for Apache Cassandra)

  Correct

  Keyspaces is a serverless, Cassandra-compatible database: existing CQL code and Cassandra drivers keep working, with no servers to patch or scale.

• CAmazon DocumentDB (with MongoDB compatibility) with elastic clusters

  Incorrect

  DocumentDB is compatible with MongoDB, not Cassandra, so the application would have to change.

• DAmazon ElastiCache for Valkey with data persistence turned on

  Incorrect

  ElastiCache is an in-memory data store used mainly as a cache. It does not speak CQL and is not a replacement for a Cassandra cluster.

Keep the API, drop the operations: a managed service that is compatible with the engine the code already uses.

• AAdd RDS read replicas and send the catalog queries to them

  Incorrect

  Replicas spread the load, but every request still runs the complex query on a database, which takes milliseconds, not microseconds.

• BMove the database storage to Provisioned IOPS SSD with more IOPS

  Incorrect

  The bottleneck is CPU spent on repeated queries, not storage I/O, and a query still cannot return in under a millisecond.

• CCache the query results in Amazon ElastiCache with a TTL, loading them on a miss

  Correct

  An in-memory cache returns repeated results in microseconds and takes the repeated queries off the database. A TTL refreshes the results after they change.

• DScale the DB instance up to the largest instance class in its family to add CPU

  Incorrect

  A larger instance absorbs more queries, but each query still runs in full, so results do not come back in under a millisecond.

Repeated, rarely changing query results plus a sub-millisecond target is the textbook case for a cache in front of the database.

• AAmazon RDS for MySQL with read replicas, and RDS Proxy for connection pooling

  Incorrect

  RDS needs DB instances to choose and size, and all writes go to one primary instance.

• BAmazon Redshift Serverless, with one table keyed on cart ID

  Incorrect

  Redshift is a data warehouse for analytics, not a store for high-volume, single-item reads and writes.

• CAmazon ElastiCache for Memcached as the only store of the carts, with no database behind it

  Incorrect

  Memcached keeps data only in memory with no persistence or replication, so carts would be lost when a node fails.

• DAmazon DynamoDB in on-demand capacity mode, keyed on cart ID

  Correct

  DynamoDB serves key-value access in single-digit milliseconds at any scale, and on-demand mode adapts to traffic with no capacity to plan.

Simple key access, huge swings in traffic and no capacity planning is the profile of DynamoDB with on-demand capacity.

• AUse the customer ID as the partition key and the order date as the sort key

  Correct

  A query on one customer's partition returns that customer's orders sorted by the sort key, newest first when read in descending order.

• BAdd a local secondary index with the tracking number as its sort key

  Incorrect

  A local secondary index shares the table's partition key, so a lookup would still need the customer ID, which the second query does not have.

• CKeep the scans, and switch the application to strongly consistent reads

  Incorrect

  Read consistency does not change how much of the table a scan reads, so both queries stay slow and expensive.

• DUse the order status as the partition key so that open orders sit together

  Incorrect

  Status has few distinct values, which concentrates traffic on a few partitions, and it answers neither query.

• EAdd a global secondary index with the tracking number as its partition key

  Correct

  A global secondary index can have a different partition key from the table, so one query finds an order by tracking number across all customers.

Design keys from the access patterns: the table's keys serve the per-customer query, and a global secondary index serves the lookup by another attribute.