I'm wondering about the rationale for using ElastiCache/SimpleQueue vs just having "Cache" and "Queue" tables inside of DynamoDB respectively.
It seems that the network latency to the Cache/Queue services would trump a lot of the performance gains, and that having EC2 treat Dynamo as it's cache/queue service would offer the same latency and throughput (since Dynamo allows a fixed low latency under any load).
Is it mainly about the price of dynamo vs other services under load?
Does anyone have any rough latency numbers comparing Dynamo with ElastiCache/SQS?
Are there other more important considerations that I'm missing which justify the additional complexity?
Thanks.
Best Answer
We're using DynamoDB and ElastiCache Redis for different reasons.
DynamoDB:
ElastiCache Redis:
So our setup most of the time is: Simple caches with high volume of requests in Redis backed by DynamoDB as the permanent and long-durable storage. With this we limit the costs as we get an implicit discount for our reads by the pay-per-instance model of Redis but also get the benefit of the redundancy of DynamoDB and are even able to use the DynamoDB query language for more complex stuff (if we need it).
Hope that helps!
Update: With the announcement of Amazon DynamoDB Accelerator (https://aws.amazon.com/de/dynamodb/dax/) we're switching over to use DAX as it is (in the end) exactly what we were doing with the combination of DynamoDB and Redis. As DAX ist fully-managed by AWS and gives us the chance to always use the DynamoDB language in our application but also get the benefits from a write-through cache like Redis.