Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Recommended way of scaling firebase by adding regions [closed]

At present I have 3 firebase projects used for an app: live, beta, development

These handle respective environments and are all within US zone.

In the future if app is used world wide, what is the recommended way to scale in EU / Asia + US? My initial instinct is to create additional firebase projects like live-eu, live-asia, but I see an issue here:

Can these projects use same app id that my US ones are currently using? I can't import data from US project as it has uid's in there, surely these wont work with auth from other projects? But I'd need to allow users to transition into other regions.

I won't be able to gather analytics from all regions in one place as well correct?

Hence the question, is there a way to scale / add multi region support in on a firebase project? Particularly interested in firestore and cloud functions, as these are the ones where latency can be reduced.

like image 834
Ilja Avatar asked Aug 22 '18 05:08

Ilja


People also ask

Is Firebase good for scaling?

Firebase is built for performance and scalability. As and when there is a change in data, Firebase helps in the calculation of the minimum set of updates needed to keep all your clients synchronized.

Which is better Firebase Realtime Database or Firestore?

Cloud Firestore also features richer, faster queries and scales further than the Realtime Database. Realtime Database is Firebase's original database. It's an efficient, low-latency solution for mobile apps that require synced states across clients in realtime.

Which method is used for modifying Firebase Realtime Database data?

For this, we can use the update method.


1 Answers

I asked in the comments but didn't get a response, so I'm assuming that your app has a READ intensive workload. For these cases, in order to reduce latency of requests coming from all over the world, you should make use of a CDN to cache static files and responses (i.e. make use of edge locations and edge computing). You don't even need to stick with Firebase for that (there are solutions like Akamai and CloudFront that may fit your needs and easily plug to your Firebase solution), but if you need to, take a look at Firebase Hosting.

If your workload is WRITE intensive, try to make use of asynchronous mechanisms, such as messaging queue, to guarantee that you give a faster feedback to the user. Usually, write operations don't need to be immediately/synchronously executed, but again, it would be good to understand your workload to give a more precise answer.

EDIT: Google recently announced Firestore -- they offer multi-region support for better availability:

A multi-region location is a general geographical area, such as the United States. Data in a multi-region location is replicated in multiple regions. Within a region, data is replicated across zones.

In terms of scalability, this is the statement they gave in their blog:

Cloud Firestore [...] is built on top of the same Google Cloud infrastructure that powers some pretty popular apps. So it will be able to scale much more easily and to a much greater capacity than the Realtime Database can.

And with the new querying structure, all Cloud Firestore queries scale to the size of your result set -- not the size of your data. This means that a search for the top 10 restaurants in Chicago for a restaurant review app will take the same amount of time whether your database has 300 restaurants, 300 thousand or 30 million. As one engineer here likes to put it, "It's basically impossible to create a slow query in Cloud Firestore."

Note that writes in Firestore have strong consistency (meaning they have higher latency compared to eventual consistency solutions).

like image 62
Fabio Manzano Avatar answered Oct 22 '22 15:10

Fabio Manzano