←back to thread

73 points pranay01 | 1 comments | | HN request time: 0.403s | source
Show context
onethumb ◴[] No.45311154[source]
This looks super interesting for single-AZ systems (which are useful, and have their place).

But I can't find anything to support the use case for highly available (multi-AZ), scalable, production infrastructure. Specifically, a unified and consistent cache across geos (AZs in the AWS case, since this seems to be targeted at S3).

Without it, you're increasing costs somewhere in your organization - cross-AZ networking costs, increased cache sizes in each AZ to be available, increased compute and cache coherency costs across AZs to ensure the caches are always in sync, etc etc.

Any insight from the authors on how they handle these issue on their production systems at scale?

replies(2): >>45311421 #>>45311444 #
jimbohn ◴[] No.45311421[source]
Assuming the "Designed for caching immutable blobs", I guess the approach is to indeed increase the cache size in each AZ or eat the cross-AZ networking costs.
replies(1): >>45312643 #
1. shikhar ◴[] No.45312643[source]
Yes, that's how we are running it at s2.dev, auto-scaled per-AZ deployments. https://www.reddit.com/r/databasedevelopment/comments/1nh1go...