A few weeks ago, I wrote about a third way to scale that doesn’t get enough attention. The idea: instead of scaling one application up or out, you run many small, independent applications. Each one handles a subset of your users and never grows large enough to need scaling. I called it “natural scaling.”
Since then, I keep running into the same example. One that fits natural scaling so well it’s almost too perfect.
Multi-country ecommerce.
Everything is different anyway
Here’s what happens when you expand your online store to a new country. The product names change. The prices change. The VAT rates differ. The catalog itself might change because some products only make sense in certain markets.
You’re not serving the same data with a different language pack on top. You’re running a different store. The data is fundamentally different.
So why fight it? Why cram all of that into one application and build the complexity to manage it? You’d need multi-tenant data isolation, per-country pricing logic, catalog filtering, localized tax calculations, all layered on top of your existing store.
Or you could give each country its own store. Separate application, separate data, separate URL. The complexity doesn’t disappear, but it moves from your application code to your operations. And that’s a trade-off worth making.
Beyond the application
The argument I hear most often: “My framework already supports multi-store setups. I can run 5 countries from one backend.”
Fair. Most ecommerce frameworks do support this. But a store isn’t an application in a vacuum. It’s an application plus everything around it: backups, monitoring, deployment pipelines, infrastructure.
When all your countries share one backend, they share everything. That includes the constraints.
Backup strategies
Regulations vary by country. Some have strict data residency requirements. Others don’t. If all countries live in one database, your backup strategy has to satisfy the most demanding regulation. That means paying for compliance everywhere, even where it isn’t required.
With separate stores, you match the backup strategy to each country’s requirements. Strict regulations for the countries that need them. A lighter approach for those that don’t. You spend money where it matters.
Maintenance windows
Every application needs maintenance at some point. Database migrations, platform upgrades, the occasional “we need 10 minutes of downtime” situation.
If your store serves customers across multiple time zones from one backend, there’s no 4 AM. Someone, somewhere, is wide awake and trying to buy something. You either accept that your maintenance window hits peak hours for some country, or you try to find the mythical window where everyone is asleep (spoiler: it doesn’t exist).
Separate stores, separate maintenance windows. Your French store goes down at 4 AM CET. Your Australian store goes down at 4 AM AEST. Each country gets maintenance during their actual off-peak hours.
And yes, some countries span multiple time zones. The U.S. is the classic example. Nothing stops you from running separate stores for the East Coast and West Coast if that’s what your traffic patterns justify. Natural scaling doesn’t care about political boundaries. It cares about what makes operational sense.
Data proximity
You want your data close to your customers. This is true for both sovereignty reasons and performance.
Everything should be behind a CDN at this point, that’s table stakes. But a CDN doesn’t solve the origin problem. Cart operations, checkout flows, account management, these are dynamic requests that hit your origin server. If that origin is in Virginia and your customer is in Tokyo, physics wins. The round trip adds latency that no amount of edge caching can fix.
With one store per country (or region), the origin server lives close to the customers it serves. When a request has to reach the origin, that origin is local. Every request is faster, not because you optimized your code, but because you shortened the wire.
The honest drawback
I won’t pretend this is free. Natural scaling trades application complexity for operational complexity. Instead of managing one store, you’re managing many.
Deploying a change means deploying it to every store. A security patch has to roll out across your entire fleet. Configuration drift becomes a real concern if you don’t have solid automation.
This is the part where you need to be comfortable operating at scale. You need reliable CI/CD pipelines, infrastructure-as-code, and the discipline to treat your stores as a fleet rather than a collection of snowflakes.
Upsun can help here. The platform is built around the idea that provisioning and managing many isolated environments should be straightforward, not a months-long infrastructure project. But even with good tooling, operating many stores is a different discipline than operating one. It’s worth being honest about that.
When this makes sense
If your multi-country expansion means localizing a landing page and swapping the currency symbol, you probably don’t need separate stores. A single application with i18n support will do fine.
But if each country has its own catalog, its own pricing, its own tax rules, and its own regulatory requirements, you’re already running different stores. You’re running them on the same infrastructure and pretending they’re one thing. That pretense has a cost in complexity, in deployment risk, and in operational constraints.
One thing to check before going down this road: your ecommerce platform’s license model. Some vendors charge per installation or per instance. If that’s the case, running 15 country-specific stores means 15 licenses. That can turn a reasonable software cost into a significant line item. It’s worth checking how your vendor counts installations (by domain, by instance, by environment) before committing to this approach.
Natural scaling says: stop pretending. Let each store be what it already is. An independent application, with its own data, its own infrastructure, and its own operational lifecycle. They can share the same codebase. They probably should. But they run independently.
It’s more stores to manage. But each one is simpler. And in my experience, many simple things are easier to operate than one complicated thing. Last modified on April 14, 2026
