I agree with iposner. Database failover redundancies are the DBA's job, not the Developer's.

There should be no metadata in the data a developer is using to help them figure out which server created the record - if you think you need that type of information, then that should be a tell-tale sign you're already headed down the wrong path.

I also don't care for some of the examples other are posting of calling another service to get an ID, well what happens when that service goes down (because you have no control over it or those who hit it) - Can we say, fail-whale?

Then there's the suggestion of creating an ID with letters and numbers in it to represent what type of record it is. You can generate this ID before displaying it to the user. If the user query's for the mnemonic-ID, you can convert it into a query that parses out the mnemonic-ID to query based on record type, numeric ID, and so on.

It is best to have a sequential numeric ID for performance purposes. It saves on space, and allows for better indexing, which equals better speed.

There are times when you do need a GUID, but I make it a point to never use them as a Primary Key. Instead, for example, I use them when creating a new login that I need to email to a user for a confirmation link. That GUID is not their User ID, instead it is linked to their User ID. If you don't want GUID's expanding your table row length, then throw them into a separate table (i.e. A table with just UserID and ConfirmationGUID, where UserID is a foreign key to the Primary Key in the User's table).