3 ms·
Hi, this is a very cool product and I am planning a project that I think could use it. The question I have tho: How do you take advantage of the gains from thi
by chrisjarvis 7y ago
Hi, this is a very cool product and I am planning a project that I think could use it.
The question I have tho: How do you take advantage of the gains from this if you still need one master strictly consistent db for writes?
Would a system design pattern to take advantage of fly.io be to have read only replicas on each geographic deploy or to only have region specific persistance? Apologies if this was already answered I read thru everything I saw. Thanks!
- mrkurt 7y agoThe "simplest" gains come from adding an in memory cache, we include Redis for this and some apps work really well just leaving the DB where it is, caching aggressively, and running close to users: https://fly.io/docs/redis/ https://fly.io/docs/redis/ Read only replicas are a great first step for most applications. I'd probably do caching first, then replicas (which are kind of like caching). Region specific persistence is one way to improve write latency, and I think the simplest for most apps. We've experimented with CockroachDB for this (it keeps ranges of rows where they're most busy), and you can actually deploy MongoDB this way.
- chrisjarvis 7y agoThanks that totally makes sense! I look forward to playing around with this.
- awoods187 7y agoPM@cockroach labs here. Which tools did you experiment with? We've been working to increase our tooling capabilities!
- mrkurt 7y agoWe got hung up with the migration tooling for popular frameworks. If we can get those migrations to work with minimal drama, we want to basically show people “global full stack” with app + cache + database.