Improve on this pattern for handling how a mobile app knows how to find it's server

Question

I'm considering how to identify server(s) to an app on a mobile device that utilises a wcf/web service.

(1) I anticipate all going well that I will need to migrate the server between hosts from time to time to handle load. I'd like to be able to do this without service disruption.

(2) I also anticipate that all going well I will want to improve scalability by seperating website hosting and wcf/web service hosting requiring an addressing change on the client. Until the app proves to get traction the server deployment will be shared on the same domain.

Rereleasing the client for this purpose at a glance seems complicated as you can't force updates on consumers and it's non trivial to distinguish between no data connection/server down and a server that's moved.

I was thinking this would be a solved problem, so thought to bounce it off the community for better ideas.

What I've come up with so far is as follows.

1. Client needs a primary and secondary URL to reference the wcf/web service. This caters for host provider changes. The old host can continue to run the service during the handover period. When succesfully deployed to the new host, the secondary/old host can be disabled. The wcf/web service is essentially stateless, so that simplifies matters somewhat.

2. At periodic intervals the client will initiate a service to request the primary and secondary URLs be supplied and then caches these. This future proofs the client to be able to (for a period of time) be instructed by the service behind the secondary URL to accept a new URL for future use while the primary URL services requests at the new URL. Once the secondary service has pointed to a new primary, the following periodic update requested from the primary will update the cached secondary URL.

What have I missed? Perhaps it can be simpler?

Answer 1

DNS is probably the way to hide your server moving to a new address. When you change your server, you update your DNS record. Put the new server in place, and once it is up and running, update the DNS record. That's all there is to do, unless I am missing something.

Edited to reflect comments :

To be sure that the change is seemless, you can reduce the TTL of your DNS entries to a very low value to be sure that the propagation is fast. For example, if before switching servers you change your TTL to 5 minutes, you ensure that you can swith your first server off 5 minutes after updating your DNS entries.

So you only need one URL, and this URL never needs to change. It answers both your first and second requirements. No need to reinvent the wheel.