Integer IDs are fine for a non-distributed app where you have a single DB and every app server is directly connected to it. The second that's no longer the cas

Integer IDs are fine for a non-distributed app where you have a single DB and every app server is directly connected to it. The second that's no longer the case, integer IDs become a nightmare. On the other hand, a well chosen UUID, can be generated anywhere and be relied on to be globally unique. So maybe your client wants to create some records on the client, sync to a local db, and then do a batched update the next time the laptop it's running on has a wifi connection. Or maybe you want to scale your databases horizontally, or distribute your app across multiple data centers, or basically make any sort of AP (ie, Available and Partition Tolerant) system. In which case, integer IDs are asking for a world of pain, but a well chosen token is great, because you can keep working efficiently when talking to your Single Source Of Integer Truth is slow or impossible. (And yes, there's other solutions to the issue. But UUIDs can solve it with a minimal amount of design and coding.) > Debugging seems a lot easier with smaller integer values rather than UUIDs My experience has been that both are just as easy, and leaking integer IDs can be a (mild) security vulnerability.