Resumo

  • O UUIDv7 começa com 48 bits de tempo Unix em milissegundos. Os outros 74 bits disponíveis são aleatórios por padrão ou podem conter precisão adicional e contadores opcionais.
  • Ordem dentro do mesmo milissegundo, recuo do relógio, esgotamento do contador e estado persistente pertencem à política do gerador. Ordenar valores de nós independentes não prova causalidade ou commit.
  • UUID é identificação, não autenticação, autorização ou capacidade de segurança. Sistemas auditáveis guardam tempo do evento, gerador, vínculo causal, sequência de commit e recibo verificável em campos próprios.

O ganho concreto está no índice

UUIDv4 distribui novas chaves aleatoriamente pelo espaço. A geração descentralizada é simples, mas inserções sucessivas podem atingir páginas distantes de um índice. O RFC 9562 criou formatos ordenados no tempo, entre outros motivos, para melhorar a localidade e permitir comparação como bytes opacos.

O UUIDv7 coloca nos 48 bits mais significativos os milissegundos desde a época Unix, sem segundos intercalares. Depois vêm versão e variante. Restam 74 bits para aleatoriedade ou para uma combinação permitida de fração de milissegundo, contador e dados aleatórios. A recomendação é preferir v7 a v1 ou v6 quando possível.

Valores gerados em milissegundos posteriores normalmente aparecem depois. Isso ajuda a agrupar inserções e navegar por tempo aproximado.

O relógio, porém, pertence ao gerador. Não é um sequenciador de transações compartilhado, uma autoridade de carimbo de tempo ou um mapa causal. O formato torna um valor temporal ordenável; não torna a fonte mais autorizada.

Dentro do milissegundo existem escolhas

Serviços rápidos produzem muitos UUIDs sob o mesmo prefixo de milissegundo. Sufixos aleatórios bem gerados reduzem colisões, mas sua ordem não corresponde necessariamente à criação.

O RFC descreve três métodos opcionais de monotonicidade: reservar bits altos para um contador fixo, usar um contador monotônico iniciado aleatoriamente ou empregar até 12 bits de precisão submilissegundo. O restante pode continuar aleatório.

Duas bibliotecas conformes podem escolher métodos distintos. Dois processos no mesmo host podem ter contadores separados. A ordenação do conjunto sempre cria uma sequência de bytes, mas não revela obrigatoriamente qual operação começou, terminou, foi confirmada ou se tornou visível antes.

Unicidade e ordem não são a mesma garantia. Entropia trata colisões. Um contador trata uma sequência local. Nenhum deles cria dependência causal entre produtores independentes.

O que fazer quando o relógio volta

Ajuste manual, sincronização, retomada de máquina virtual e falha podem fazer a hora recuar. O RFC 9562 orienta implementações preocupadas com monotonicidade a comparar o novo UUID com o anterior e corrigir uma regressão.

O gerador pode manter o timestamp anterior e incrementar um contador, esperar a hora física avançar, colocar o timestamp à frente ou retornar erro. Cada resposta muda a promessa.

Manter o valor anterior protege a ordem local, mas afasta o número do presente. Esperar custa disponibilidade. Avançar produz um tempo futuro intencional. Falhar recusa a emissão.

A especificação também permite alterar, desfocar ou suavizar o timestamp e não garante proximidade com a hora real. Decodificar os primeiros bits não revela a política utilizada; ela precisa de registro próprio.

Estado persistente define o alcance

Último timestamp, contador e aleatoriedade podem ser guardados de forma estável. Após reinício, o estado ajuda o gerador a continuar acima dos valores antigos. A persistência é opcional; começar como um novo lote é permitido, com maior risco de colisão e consumo de entropia.

Uma promessa de monotonicidade deve dizer até onde chega: thread, processo, host, cluster ou região. Um contador em um contêiner não ordena o vizinho. O RFC observa que um banco monolítico pode obter melhor resultado gerando os UUIDs por conta própria.

Nós distribuídos podem gerar de forma independente. Bits aleatórios ajudam contra duplicação, mas não oferecem um sequenciador comum. Juntar e ordenar depois é bom para paginação; não cria uma ordem de commit que nunca existiu.

NTP não é um protocolo causal

NTP e as práticas do RFC 8633 elevam a qualidade dos relógios. Não garantem igualdade perfeita a todo instante e não dizem que um evento depende de outro.

Se A grava e depois envia uma mensagem a B, a diferença entre os relógios pode posicionar o UUID de B antes do de A. Uma tentativa repetida pode receber a chave em outro ponto do ciclo. Dentro do milissegundo, os nós podem usar regras de sufixo diferentes.

A evidência causal vem da aplicação: B referencia a mensagem de A, o banco atribui uma posição de commit, ou um livro emite recibo após aceitar o ato. Esses campos convivem com UUIDv7. O UUID fornece uma chave e uma pista temporal; a referência ou sequência sustenta a afirmação forte.

Isso não é defeito do padrão. O RFC 9562 define identificadores e práticas de geração, não consenso distribuído ou relógio global.

Não transformar conveniência em testemunho

Ordenar UUIDs e chamar o resultado de “ordem dos eventos” pressupõe relógios comparáveis, mesma política de recuo, métodos compatíveis no milissegundo, emissão no marco correto e ausência de pré-geração, repetição ou importação histórica.

Qualquer hipótese pode falhar e o UUID continuar válido. Ele pode nascer antes de uma transação revertida, antes da entrega de uma fila ou hoje para um registro antigo. Um timestamp alterado por política também continua dentro do espaço permitido.

O esquema auditável separa identificador; tempo do evento e fonte; ingestão; identidade e versão do gerador; predecessor causal; sequência de commit ou recibo. Nem todo sistema precisa de tudo, mas deve declarar o que pretende provar.

Se restar apenas o UUIDv7, a formulação honesta é “ordem aproximada pelo relógio do gerador”. Não se decide uma disputa com isso sozinho.

Possuir um UUID não concede acesso

O RFC 9562 alerta que UUIDs não devem ser presumidos difíceis de adivinhar e não podem servir como capacidade de segurança cuja posse abre um recurso. A regra vale mesmo com boa aleatoriedade.

Resistência a colisões, imprevisibilidade e autoridade são propriedades separadas. Entropia e CSPRNG ajudam as primeiras; não autenticam o portador nem autorizam a ação.

O timestamp ainda revela criação aproximada e um contador pode sugerir volume. RFC 4086 e RFC 8937 explicam por que aparência aleatória não equivale a segurança.

A API autentica a pessoa, autoriza a operação e protege integridade por meios próprios. Uma chave bem formada não prova propriedade.

Testar a promessa real

Para localidade, medir o banco e o índice. Para paginação monotônica local, documentar fronteira do gerador, método no milissegundo, estado persistente e tratamento de recuo.

Para auditoria distribuída, registrar local de emissão, fonte de relógio, versão de política e etapa de ciclo de vida. Acrescentar relação causal e posição de commit. Se terceiros dependem da ordem, emitir recibo verificável.

Os testes incluem rajadas no mesmo milissegundo, esgotamento, reinício, perda de estado, saltos de relógio, partição regional e fusão de fluxos. Assim o formato pode cumprir bem sua função sem carregar uma autoridade que não promete.

Fontes