You are creating a new API for video game scores. Reads are 100 times more common than writes, and the top 1% of
scores are read 100 times more frequently than the rest of the scores. What’s the best design for this system, using
DynamoDB?
A.
DynamoDB table with 100x higher read than write throughput, with CloudFront caching.
B.
DynamoDB table with roughly equal read and write throughput, with CloudFront caching.
C.
DynamoDB table with 100x higher read than write throughput, with ElastiCache caching.
D.
DynamoDB table with roughly equal read and write throughput, with ElastiCache caching.
Explanation:
Because the 100x read ratio is mostly driven by a small subset, with caching, only a roughly equal number of reads to
writes will miss the cache, since the supermajority will hit the top 1% scores. Knowing we need to set the values roughly
equal when using caching, we select AWS ElastiCache, because CloudFront cannot directly cache DynamoDB queries,
and ElastiCache is an excellent in-memory cache for database queries, rather than a distributed proxy cache for content
delivery. … One solution would be to cache these reads at the application layer. Caching is a technique that is used in
many high-throughput applications, offloading read activity on hot items to the cache rather than to the database. Your
application can cache the most popular items in memory, or use a product such as ElastiCache to do the same.
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.
CachePopularItem
D
D
Only a little data is going to be accessed repeatedly so using Elastic-cache with roughly equal Read-Write capacities is the best solution.
D
The question states two distinct issues:
1) 1% of scores are read 100 times more frequently than the rest of the scores
2) Reads are 100 times more common than writes
The first is addressed by Elasticache, and depending on the size of the cache and the actual read distribution, some of the second may be as well.
However, the second has other implications:
ALL items will be read 100x more than they are written to. Thus, all items will be read – not just 1%, and they will be read 100x as often as written in each case.
Depending on consistency, reads ‘cost’ only 25% or 12.5% of writes (4k vs 1k size for units), that is, writes are 4x or 8x as expensive as reads. Also, reads can only exceed writes by 3x in any partition (3000 vs 1000 units in partition capacity).
We KNOW we will never use as many write units as read units by this problem statement – but specifying these unused write units can force a partition split – decreasing the units available to each partition.
100x is probably not the right multiplier, but I choose ‘C’.