O que é o UUID v7 e por que ele foi criado
O UUID v7 é um identificador universal de 128 bits representado como uma string de 36 caracteres no formato xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx, onde os primeiros 48 bits correspondem a um timestamp Unix em milissegundos, seguidos por bits aleatórios. Essa estrutura resolve um dos problemas mais incômodos do UUID v4: a falta de ordenação temporal. Enquanto o UUID v4 é completamente aleatório — o que fragmenta índices de banco de dados baseados em B-tree —, o UUID v7 coloca a data de criação no início do identificador. Com isso, registros criados sequencialmente tendem a aparecer próximos no índice, melhorando a performance de inserção e consulta em bancos relacionais e NoSQL.
Historicamente, a IETF padronizou os UUIDs na RFC 4122 (2005), que definiu as versões 1 a 5. O v7 é uma proposta mais recente (atualmente um draft, mas já amplamente adotada) que combina a vantagem temporal do UUID v1 — que usava timestamp + endereço MAC — com a imprevisibilidade do v4. O formato v7 não expõe informações do hardware nem da máquina, pois a parte aleatória substitui o endereço MAC, mantendo a privacidade do gerador. A timestamp é contada a partir de 1º de janeiro de 1970 (Unix epoch), em milissegundos, o que dá cerca de 9.000 anos de margem antes de ocorrer overflow.
Como o gerador de UUID v7 do BroBroGo funciona
A página oferece um formulário minimalista: um campo para definir a quantidade de UUIDs (entre 1 e 100, inclusive), dois interruptores (maiúsculas/minúsculas e hífens) e um botão de ação implícita — qualquer alteração em qualquer opção regenera imediatamente toda a lista. O usuário nunca precisa clicar em "Gerar"; a resposta é instantânea. Os UUIDs são exibidos em uma lista vertical, cada um clicável individualmente para copiar apenas aquele identificador para a área de transferência. Há também um botão "Copiar todos" que copia todos os UUIDs da lista para a área de transferência de uma só vez.
A geração ocorre inteiramente no navegador, utilizando a API crypto.getRandomValues() do JavaScript, que fornece números aleatórios criptograficamente fortes. Nenhum dado — nem a quantidade, nem os UUIDs gerados — é enviado para o servidor do BroBroGo. Após a primeira geração, uma mensagem de status indica "Pronto." ou "Gerado.", e após a cópia em massa aparece "Copiado tudo!". As opções disponíveis são:
| Opção | Valores possíveis | Efeito na saída |
|---|---|---|
| Formato | UUID v7 (fixo) | Gera UUIDs exatamente no formato da versão 7 (timestamp + aleatoriedade). |
| Quantidade (Count) | Inteiro entre 1 e 100 | Controla quantos UUIDs são exibidos na lista. |
| Maiúsculas | Ligado/Desligado | Quando ligado, as letras hexadecimais (a-f) são exibidas em maiúsculas. |
| Hífens | Ligado/Desligado | Quando desligado, os hífens são removidos, resultando em uma string de 32 caracteres contínua. |
A mudança de qualquer opção descarta a lista anterior e gera um novo conjunto completo de UUIDs. Isso significa que se o usuário estiver com 50 IDs e reduzir o count para 10, os 10 novos UUIDs serão completamente diferentes dos anteriores — não uma sublista. Esse comportamento evita confusão sobre quais IDs correspondem a qual configuração.
A estrutura do UUID v7: timestamp e aleatoriedade
Cada UUID v7 é composto de 128 bits no total. Os 48 bits mais significativos são o timestamp Unix em milissegundos. Os 80 bits restantes são divididos em campos de versão (4 bits, valor fixo 0111 = 7), variante (2 bits, valor 10) e 74 bits de aleatoriedade pura. Na representação textual de 36 caracteres, os primeiros 12 caracteres (após ignorar hífens) correspondem ao timestamp. Por exemplo, no UUID 018f9a3e-7b1c-7a00-8000-123456789abc, os primeiros oito caracteres (018f9a3e) e o nono ao décimo segundo (7b1c) juntos formam a representação hexadecimal do timestamp.
A inclusão de hífens é opcional na ferramenta. O padrão RFC exige hífens nas posições 8-4-4-4-12, mas muitos sistemas armazenam UUIDs como strings de 32 caracteres sem hífens para economizar espaço ou facilitar a indexação. A opção de maiúsculas/minúsculas também não altera o valor do UUID; a letra a minúscula e A maiúscula representam o mesmo nibble. Contudo, alguns bancos de dados (como PostgreSQL) tratam UUIDs como binários e não se importam com case, enquanto outras aplicações podem comparar strings de forma sensível a caixa. A ferramenta permite que o usuário escolha o formato que melhor se adapta ao seu pipeline.
Vale notar que, como a timestamp tem resolução de apenas 1 ms, dois UUIDs gerados dentro do mesmo milissegundo podem aparecer em qualquer ordem na saída. A parte aleatória não é monotônica — ou seja, não há garantia de que o segundo UUID gerado terá um valor aleatório maior que o primeiro. Se a ordenação estrita dentro do mesmo milissegundo for crítica (por exemplo, em sistemas de log de eventos com alta concorrência), o UUID v7 não oferece essa garantia. Outros formatos, como o ULID, têm mecanismos opcionais para monotonicidade, mas a implementação padrão também sofre da mesma limitação.
UUID v7 vs UUID v4 vs ULID: quando usar cada um
A escolha entre esses identificadores depende principalmente do equilíbrio entre ordenação temporal, imprevisibilidade e compatibilidade. A tabela abaixo compara as principais características:
| Característica | UUID v4 | UUID v7 | ULID |
|---|---|---|---|
| Tamanho da string | 36 caracteres (com hífens) | 36 caracteres (com hífens) | 26 caracteres (Crockford base32) |
| Bits totais | 128 | 128 | 128 |
| Bits de timestamp | 0 | 48 (ms desde Unix epoch) | 48 (ms desde Unix epoch) |
| Bits aleatórios | 122 | 74 | 80 (inclui parte de timestamp?) |
| Ordenação temporal | Nenhuma | Por timestamp (não estrito no mesmo ms) | Por timestamp (não estrito no mesmo ms) |
| Resistência a colisão | Muito alta (122 bits aleatórios) | Alta (74 bits aleatórios) | Alta (80 bits aleatórios) |
| Fragmentação de índice | Alta | Baixa (devido ao prefixo temporal) | Baixa (prefixo temporal) |
| Padrão formal | RFC 4122 (2005) | Draft IETF (proposto) | Especificação aberta (não IETF) |
O UUID v4 continua sendo o mais difundido e é apropriado quando não há necessidade de ordenação por criação (ex.: identificadores de sessão temporários). O UUID v7 é superior para chaves primárias em bancos de dados onde a inserção de novos registros deve evitar a reorganização constante do índice B-tree — o chamado page split. O ULID tem a vantagem de ser mais curto (26 caracteres) e legível em URLs, mas não é nativamente suportado por todas as linguagens e frameworks.
Outra diferença prática: o UUID v7, por ter menos bits aleatórios (74 contra 122 do v4), tem uma probabilidade de colisão ligeiramente maior. Mas, na prática, 2^74 combinações (cerca de 1,9 × 10^22) ainda são astronomicamente altas para a maioria dos sistemas. Se o volume de IDs ultrapassar bilhões por milissegundo, aí sim seria necessário considerar uma fonte de monotonicidade adicional.
Casos de uso e aplicações práticas
O UUID v7 é ideal para sistemas distribuídos onde cada nó gera seus próprios identificadores sem depender de um coordenador central. Bancos de dados como CockroachDB e algumas configurações do MySQL usam variantes de UUID temporal para melhorar a performance de gravação. Ao substituir chaves primárias baseadas em UUID v4 por v7, administradores de banco de dados relatam redução significativa na fragmentação de índices e no número de páginas lidas durante inserções em lote.
Outras aplicações comuns:
- Sistemas de mensageria: cada mensagem recebe um UUID v7 que permite ordenar por chegada (dentro da precisão do milissegundo).
- Auditoria e logs: o timestamp embutido elimina a necessidade de separar o carimbo de data/hora do identificador.
- Event sourcing: eventos ordenados por UUID v7 facilitam a reconstrução do estado sem depender de relógios de sistema externos.
- Microsserviços: cada serviço gera IDs localmente; como a timestamp é compartilhada, a ordenação aproximada se mantém entre serviços (desde que os relógios estejam sincronizados via NTP).
A geração local no navegador, como a implementada na ferramenta, é particularmente útil para prototipação e testes. O desenvolvedor pode gerar rapidamente dezenas de UUIDs v7 com diferentes configurações (com/sem hífens, maiúsculas/minúsculas) e copiar os que se encaixam no formato exigido pelo seu sistema de destino. Como nada é enviado ao servidor, não há risco de vazamento de dados durante a fase de desenvolvimento.
Perguntas frequentes (FAQ)
Posso gerar mais de 100 UUIDs v7 de uma vez?
A ferramenta está limitada a 100 IDs por clique. Para gerar mais, é necessário executar múltiplas gerações. Essa restrição existe para evitar sobrecarga do navegador e garantir resposta instantânea.
Por que os UUIDs v7 não são estritamente ordenados quando gerados no mesmo milissegundo?
O UUID v7 não define um mecanismo monotônico para a parte aleatória. Dois IDs criados no mesmo milissegundo terão timestamps idênticos; a ordem na saída é determinada pela aleatoriedade, que não é garantida como crescente. Se a ordenação exata for necessária, o desenvolvedor deve adicionar um contador incremental ou usar um formato como o Snowflake.
O UUID v7 é seguro para uso criptográfico?
Não. Embora a parte aleatória seja gerada com crypto.getRandomValues() (criptograficamente forte), o UUID v7 como um todo não é projetado para ser imprevisível o suficiente para tokens de autenticação ou chaves de sessão. Um atacante que conheça o timestamp pode reduzir o espaço de busca. Para fins criptográficos, prefira funções de hash ou geradores específicos.
A ferramenta envia meus UUIDs para o servidor do BroBroGo?
Não. Toda a geração ocorre localmente no seu navegador, usando a API de criptografia disponível no JavaScript. Nenhum dado é transmitido para nenhum servidor.
Para que serve a opção "maiúsculas"?
Controla apenas a apresentação visual. UUIDs em maiúsculas ou minúsculas representam o mesmo valor binário. Alguns sistemas (ex.: Amazon DynamoDB) tratam UUIDs como strings e podem exigir um formato específico. A opção permite adequar a saída ao padrão do seu projeto.
Quantos bits de aleatoriedade o UUID v7 realmente tem?
Dos 128 bits, 48 são timestamp, 4 são da versão, 2 da variante e os 74 restantes são aleatórios. Isso resulta em cerca de 2^74 ≈ 1,9 × 10^22 combinações possíveis para o componente aleatório, o que é suficiente para praticamente todos os cenários de uso.