undefined | Better HN

0 pointsmanmal3y ago0 comments

I think that's an interesting idea.

Here's a post that benchmarked multi-region Postgres (Elixir/Phoenix on fly.io): https://nathanwillson.com/blog/posts/2021-09-25-fly-multi-db...

According to the post, for some users (residing in Japan, and the primary instance being located in Amsterdam), a query could take ~200ms (median). If multiple queries are performed for each request, that could mean 1 second or more per API call - not so great if that's the case for multiple seconds after each write. I think this would eventually lead to putting more code in stored procedures, begging the question: why not use a distributed DB like Fauna in the first place?

Alternatively, the replication problem could be accounted for in the app itself. E.g. the SPA or the edge instance could retry reads following a write until the change from the primary instance has propagated, and up until then pretend that everything went fine. In case a write isn't replicated within 10 seconds or so, show an error to the user and let them retry the write action. This could lead to duplicate entries, but I'd estimate the chance for that to be quite low.

0 comments

danpalmer3y ago

Yeah 200ms to the database feels essentially useless for a webapp. I'd normally expect <5ms for a typical app, and <1ms is ideal – that usually means the same rack or very close.

This time all adds up. For a moderately complex webapp something like 10-20 queries isn't unheard of (even when you're careful about N+1 queries and caching). If each of those is taking ~5-10ms, add the network latency, and you're at ~50-150ms, which is pretty much your time budget for most end-user-facing webapps.

This is one of the problems with compute at the edge, you have to be much smarter about these things because there are a lot more network roundtrips between your app and database than there are between your customer and your app. Edge replicas help but still complicate things.

j / k navigate · click thread line to collapse