News for hackers. Stuff that matters.

A comment on AWS services to avoid. Parent comment

Re:AWS services to avoid by jdc0589 on Sunday May 10, 2020 @05:49PM (#23136575)
piggybacked off Dynamodb in AWS for now unfortunately; so its more "the entire system is active-active, not just the redis bit". Reads always go to Redis in every region (no read-through), writes go to dynamodb (in global table config). Then there's a worker in each region consuming the dynamo stream and keeping it's region's redis in sync

Worker is a DIY stream consumer implementation. The stream -> lambda integration works, but its super limited (and ~300ms slower to get new events on average)

[ Parent | on HN ]
Re:AWS services to avoid by jdc0589 on Monday May 11, 2020 @10:37AM (#23142593)
* writes are multiplexed to redis and dynamo in the origin region.
[ Parent | on HN ]
Re:AWS services to avoid by manigandham on Monday May 11, 2020 @07:19PM (#23148485)
Why is the origin region Redis not also a reader of the replication stream? Just for latency?
[ Parent | on HN ]
Re:AWS services to avoid by jdc0589 on Tuesday May 12, 2020 @02:11PM (#23157508)
yep. in this specific use case there can be pretty fast reads after a write, and dynamo stream latency is not great even intra-region.

Via the lambda integration you should probably expect ~1000ms p99 latency intra-region, and ~2100ms p99 from, e.g, east-1 to west-2. Shave maybe 200-300ms off of those numbers if you do a DIY stream consumer without the aws provided lambda connector.

[ Parent | on HN ]