What’s inside
This week’s Glocalization fact 🌎
Why this is worth caring about
Product friction
If you’re building for this market, keep this in mind
Where we can help
About us
This week’s Glocalization fact 🌎
The distance between your frontend server and the database is more important than the distance between your customer and the frontend server.
Photo by Mahdis Mousavi on Unsplash
Why this is worth caring about
When users interact with a web-based app, their browser (the frontend) has to submit this interaction to the web server (backend), which then communicates with the database, performs logic, and serves a response back to the frontend.
For example, when a user clicks “View My Account”, their browser has to ask the backend to pull data on the user from the database before serving the data back to the browser.
In a lot of web apps, the distance between a user and a web server may not be the slow part anymore. CDNs, caching, and modern routing often reduce that latency.
Once a request hits the backend, that server has to interact one or more times with the database. The backend server has to wait for all database queries to conclude before continuing its logic and serving data to the frontend. Each of these database questions goes over the network.
Some backends are co-located with their database, but this can change as the application grows globally. You might try to balance geographic distance between multiple regions and your application, or have a restriction regarding where you can host your users’ data.
If your frontend is in the US and your database is in Asia, every query is making that trip across the ocean and back before anything can move on. Often, each user interaction requires many database interactions. Because of this, a request often spends more time waiting on the database than waiting on the user’s internet connection.
This means that and database location relative to the backend server ends up mattering more than user location.
Product friction
Global apps are possible, but using a single database across regions introduces tradeoffs that show up directly in product behavior.
Separating databases by region reduces these delays, allowing most user interactions to read and write data closer to where requests are handled. This approach also aligns with data residency and regulatory requirements in many regions, where certain user data must remain within geographic boundaries.
However, fragmenting your database by region introduces a lot of complexity to your product architecture, and in many cases you will still have to synchronize and duplicate data across your databases.
You will have to carefully architect the numbers and locations of your backend server(s) and database(s) to minimize latency for your global audience. In many cases, this might mean fragmenting your database per region so you can situate a backend + database pair near your user centers.
Whatever structure you choose, keep in mind that the distance between users and the backend server is likely not the most important component when minimizing delay.
If you’re building for this market, keep this in mind
Your backend server talks to your database far more frequently than your users talk to your backend server.
Understand which data needs to be central (and may require some latency) and which data benefits from being local (and be rapidly available).
Some centralized data can be synchronized or replicated across boundaries to support a series of localized databases.
The outcome of fragmenting your database is not that global apps behave the same everywhere, but that response times are more consistent across regions when data locality is designed in from the start.
Where we can help
Download our 🆓 open source code.
Purchase our premium plugins.
Talk to us about a custom software project.
About us
Glocalized is written by Ruoom Inc., an open source software company based in Austin, TX.