Conceitos
IDs ordenáveis no tempo (layout Snowflake)
Intuição
Imagine vários caixas de uma loja emitindo senhas de atendimento sem conversar entre si. Para que nunca dois caixas entreguem a mesma senha, cada senha leva escrito o horário, o número do caixa e um contador daquele instante. Como o horário vem primeiro, senhas emitidas mais tarde tendem a ter número maior, e ninguém precisou perguntar nada a ninguém para gerá-las.
Como funciona
No código do Snowflake de 2010, o ID de 64 bits é composto, do bit mais alto ao mais baixo, por um timestamp em milissegundos (contado a partir de uma época própria), um datacenter ID de 5 bits, um worker ID de 5 bits e uma sequência de 12 bits. Como o timestamp ocupa os bits altos, IDs gerados mais tarde tendem a ser numericamente maiores; a ordem numérica segue o relógio local de cada máquina, e o código lido não afirma garantias mais finas de ordem entre máquinas diferentes. Dentro do mesmo milissegundo, a sequência diferencia os IDs do mesmo worker; se ela estoura, o gerador espera o próximo milissegundo. A unicidade entre máquinas fica garantida se cada gerador receber um par datacenter/worker distinto, o que o código não garante (ele só valida a faixa de 0 a 31 e não impede pares repetidos) e portanto é responsabilidade de quem opera. A unicidade depende também do relógio: o gerador guarda o último timestamp usado e, se o relógio atual é menor, se recusa a emitir e lança uma exceção até o relógio alcançá-lo, preferindo ficar indisponível a arriscar um ID repetido. Esse último timestamp fica só em memória, então a proteção não cobre reinícios do processo. A alternativa do Flickr é o ticket server: um banco dedicado cujo cliente executa REPLACE INTO numa tabela de uma linha e lê LAST_INSERT_ID(), com dois servidores dividindo pares e ímpares para tolerar falhas; cada ID custa uma escrita num banco central, em troca de números sequenciais e compactos.
Na prática
Quando os dados estão espalhados por muitos bancos e a coluna auto-increment de cada um deixa de bastar, o layout timestamp + worker + sequência permite que cada gerador crie chaves únicas, compactas e aproximadamente ordenadas no tempo, sem coordenação no momento de gerar. O custo operacional é garantir identificadores de worker distintos e monitorar o relógio das máquinas, já que um relógio que recua faz o gerador parar de emitir. Se você prefere números sequenciais e aceita uma escrita num banco central por ID, o ticket server do Flickr, deliberadamente simples, é a alternativa descrita no post.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.