How useful is it to deploy an app closer to the user with a shared database in one location?

I have an app with a central database. The app is used worldwide.

I was thinking how useful it is to spawn instances closer to the user (e.g. in iad and cdg) although the database sits just at one location (cdg). What’s the impact for the latency?

The US user would use the closer iad instance. However it needs to gather the data from the database in cdg, so the latency is high anyway.

Any thoughts on this?

App servers far away from the database instance are usually bad.

The best setup is a replica in each region and fly-replay for requests that make writes. We have an article about how this works with our infrastructure, including some notes on why latency between app and DB is so poor: Globally Distributed Postgres · Fly

What kind of app are you running? If it’s Rails or Phoenix, we have libraries that make global read replicas almost transparent. If it’s another framework, we have overview docs. We can help here too!

1 Like

Thanks @kurt. That’s my understanding too.
The problem is that most of my customers expect to have data residency in one location (Germany). So the DB lives in Germany. Therefore I can’t setup read replicas outside of Germany.
However due to the nature of the app (Slack App), the app is accessed mostly from the US (even for german customers). :clown_face:

Oh interesting! Data residency makes things complicated. :slight_smile:

I think I’d just run my app in Germany if I were you. If there’s data you can cache outside of germany, you could setup a Redis cache with replicas in the US. But definitely keep the VMs in the same regions as your data or cache.