While DynamoDB has millisecond latency (6ms ~ 10ms if partition scheme is designed properly), and In-memory DB will offer microsecond latency. Essentially moving to in-memory DB would remove 10ms from our overall latency.
If network + compute latency is 30ms, and DB fetch is 10ms, total of 40ms, how much value does in-memory DB bring if the overall latency goes from 40ms to 30ms for a service that needs to be as low latency as possible?
From my research in-memory is best used when there is a large read requests on a single partition key in order to solve hot-partition problems. We will have large number of read requests, but if we don't have a hot partition problem and requests will be distributed evenly throughout different partition keys, does an in-memory DB not bring that much value other than the 10ms savings in latency?
Thanks
Like you state, in memory databases are best when massive amounts of reads are pointed to a single partition or key. DynamoDB would limit strongly consistent reads to 3000 per second.
If you can tolerate the small latency increase a database like DynamoDB would be much more beneficial, being serverless and HTTP based means it's really easy to develop with.