 Discord uses snowflake IDs to uniquely identify things such as accounts, messages, and channels without the need for a central ID generation system. Twitter also uses a slightly different form of snowflakes to generate IDs for things such as tweets. I'll explain what's different about Twitter's snowflakes after I explain the Discord variant though. Let's take a look at what snowflakes are and how they're generated. While snowflakes are usually used as base 10 numbers, it's easier to understand what's going on if we look at the raw 64 bits going into that base 10 number. 42 bits represent the timestamp. It's the number of milliseconds since the Discord epoch, which is the beginning of January 1st 2015 in UTC. The next 5 bits are the worker ID, which is a value assigned to each worker thread by their parent process. Threads are assigned a worker ID by their parent process, and the worker IDs are unique among the threads spawned by that parent process. After that is 5 bits for the process ID, which is a unique value assigned to each server process. This results in a maximum of 32 threads per process, and a maximum of 32 processes. Due to this low number of processes in comparison to the number of Discord users, I'm pretty sure Discord uses service specifically dedicated to generating snowflakes, and the same for Twitter. Finally, the remaining 12 bits are the sequence number. Discord is incremented for each ID generated, and loops are ran out every 4096 IDs. Discord's implementation appears to reset the sequence number to 0 every millisecond, unlike the implementation I'm showing you now, although this is really just an implementation detail and doesn't have any real impact on uniqueness since the timestamp is also changed every millisecond. So, how does this ensure uniqueness among workers? The sequence number is key here. In order for the same ID to be generated twice, they would need to share all four components. The two IDs would need to be generated at the same millisecond by the same worker thread and with the same sequence numbers. Since there are 4096 possible sequence values, this would mean that a duplicate ID could only be generated if a worker thread generated 4096 IDs in the same millisecond. If such a case were to happen, Discord's snowflake generating code would likely notice though and stop generating IDs until the next millisecond. Now let's look at how Twitter implements this. Twitter's implementation differs in a few ways. Firstly, the leftmost bit is reserved instead of being a part of the timestamp. Secondly, the process ID and the worker ID are combined into a single 10-bit value. And thirdly, Twitter uses a different epoch. November 3rd, 2010, at 1.42 am, UTC 974 milliseconds into the second. My guess is that this oddly specific date is the time at which someone at Twitter was developing their snowflake implementation. That's it. Thanks for watching.