Reading through this my first gut instinct is that using a DNS service (I've used Dynect in the past) could work, but you didn't include enough information to confirm if that's good/bad advice. What you probably should do is think about your workload and decide your tolerance for errors. Consider an average request:
- Client does a dns lookup on the hostname (1)
- The client does whatever else and sends an HTTP POST request to that IP (2)
- Traffic hits the server side network and routes/proxies to the approriate backend (3)
- Backend processes the request and returns a status to the client (4)
You could accomplish what you want at any of those 4 points:
1: This is easy because a provider handles the magic, it's also the least(?) reliable because best case scenario it's using an IP I could spoof to determine where traffic comes from
2: The client itself can send location data (this is ideal especially on mobile because the app would know best what the location is). Obviously this requires the most work and again can obviously be spoofed
3: A Network level hook (like BGP) or some logic in a proxy (like nginx + lua) could route based on the HTTP headers
4: The backend code could also hit the headers, this becomes a matter of having 1 server or cluster with a shared (or sharded) database.
All those solutions have tradeoffs, additionally it's worth considering what the backend might look like. If you're planning on doing a tradition LAMP (or Python or Ruby) application, that many POSTS will kill you on invoking a PHP/Ruby/Python interpreter, no matter how small the work-load is.
Good luck!