Following question is more about best-practices than a real problem - nevertheless, I'd like to know how to do it in best way.
Given a service, that can operate in multiple countries/geo-areas, one probably start simple before even scaling is needed. A design would contain a single DB and single piece of infrastructure. An API endpoint(s) would look like this:
Now imagine that service grew a lot, and there is a need to create separate piece of infrastructure per each country/geo-area where our service operates. Would you do:
Stay with above API format, and route to shards based on queryString param from api url?
Create new API endpoints that have country/geo-area in url, e.g.
Put country/geo-area to server part of url, e.g.
I see that Option 1) has a pros of not breaking contracts. But I'm not sure that routing based on queryString is good idea at all.
Option 2) a 3) breaks previous API contracts (clients that uses it must update) and it forces clients to react on server's infrastructure changes, which is also a design-smell in my opinion.
Designing for sharding from very beginning is also not an option, as you don't know if you ever need it.