FlowingDev

UUIDs, explicados: o ID único que não pisa no calo de ninguém

Um UUID é um número de 128 bits usado para identificar informações de forma única em sistemas de computador, garantindo virtualmente que nunca haverá dois iguais.

Testar a ferramenta: Gerador de UUID

Em uma frase

Um UUID é um número de 128 bits que funciona como um número de série único para literalmente qualquer coisa que você possa imaginar em software, com uma chance ridiculamente baixa de ser criado duas vezes.

O problema que ele resolve

Nos primórdios da computação, controlar as coisas era simples. Seu primeiro usuário era o ID 1, o segundo era 2, e assim por diante. Esse "inteiro auto-incrementável" funcionava muito bem... desde que você tivesse apenas um banco de dados e um servidor criando todos os registros.

Aí a internet aconteceu. E os sistemas distribuídos. E os microservices. E os aplicativos offline-first.

De repente, você tinha vários computadores precisando criar coisas novas (usuários, posts, produtos, entradas de log) ao mesmo tempo, sem conversar entre si. Se um servidor em Dublin e um servidor em Tóquio tentassem criar "o próximo" registro, ambos criariam o registro #5830. Quando seus bancos de dados fossem sincronizados mais tarde, você teria uma colisão. Qual registro é o verdadeiro #5830? O caos se instala.

Este é o problema central que os UUIDs (Universally Unique Identifiers) resolvem: geração de IDs únicos de forma descentralizada e não coordenada. Um desenvolvedor em um laptop em uma cafeteria pode criar um ID para um novo item de lista de tarefas e ter a certeza estatística de que ninguém mais, em qualquer outro computador, em toda a história e futuro do universo, jamais irá gerar aquele mesmo ID exato. Isso permite que os sistemas criem identificadores únicos de forma independente, abrindo caminho para o software robusto e distribuído do qual dependemos hoje.

Como funciona por baixo dos panos

Em sua essência, um UUID é apenas um número grande: 128 bits de comprimento. Isso dá 2¹²⁸ combinações possíveis, o que é aproximadamente 340 undecilhões (um 3 seguido de 37 zeros). Para colocar isso em perspectiva, se você gerasse um bilhão de UUIDs a cada segundo, levaria cerca de 10 bilhões de anos para esgotar todas as possibilidades. A chance de dois UUIDs gerados aleatoriamente colidirem é astronomicamente pequena.

Anatomia de um UUID

Embora seja um inteiro de 128 bits, nunca o vemos dessa forma. Ele é quase sempre representado como uma string hexadecimal de 32 caracteres, dividida em cinco grupos com hifens.

Um UUID típico (Versão 4) se parece com isso: 123e4567-e89b-42d3-a456-426614174000

Vamos destrinchar esse formato:

  • Estrutura: 8-4-4-4-12 (representando 32 caracteres hexadecimais, para um total de 36 caracteres incluindo hifens).
  • Dados: Cada caractere hexadecimal representa 4 bits (um "nibble"). 32 caracteres * 4 bits/caractere = 128 bits.
  • Os Números Mágicos: Vê o 4 no início do terceiro grupo (42d3)? Esse 4 não é aleatório. Ele especifica a versão do UUID (neste caso, Versão 4). O primeiro caractere do quarto grupo (a456) também tem um significado especial; ele identifica a variante, garantindo que esteja em conformidade com o layout padrão. Para a maioria dos UUIDs que você verá, será um dos seguintes: 8, 9, A ou B.

Um Tour pelas Versões

A descrição desta ferramenta especifica a Versão 4 (v4), que é o tipo mais comum. Mas existem várias versões, cada uma com uma estratégia de geração diferente.

Versão Método de Geração Caso de Uso
v1 Timestamp + endereço MAC do computador gerador. Quando você precisa de ordenação baseada em tempo. (Raramente usado hoje por questões de privacidade ao expor o endereço MAC).
v2 Igual à v1, mas com informações POSIX UID/GID adicionais. Extremamente raro. Uma formalização da v1.
v3 Hash MD5 de um "namespace" e um "nome". Determinístico. Com o mesmo namespace e nome, você sempre obtém o mesmo UUID. (Menos comum, o MD5 tem suas fraquezas).
v4 Pura Aleatoriedade. A escolha padrão. Quando você só precisa de um ID único e não se importa com mais nada.
v5 Hash SHA-1 de um "namespace" e um "nome". A escolha determinística moderna. Mesma ideia da v3, mas com uma função de hash mais forte.

Gerando um UUID Versão 4

Gerar um UUID v4 é conceitualmente simples:

  1. Gere 128 bits de dados aleatórios criptograficamente fortes.
  2. Ajuste alguns bits específicos para definir os campos de "versão" e "variante", conforme exigido pelo padrão.
  3. Formate os 128 bits resultantes como uma string hexadecimal com hifens.

Aqui está o pseudocódigo para o passo de "ajuste":

// Assumindo que `bits` é um array de 128 bits aleatórios (0s e 1s)

// Define a versão para 4 (0100)
bits[48] = 0;
bits[49] = 1;
bits[50] = 0;
bits[51] = 0;

// Define a variante para '10x'
bits[64] = 1;
bits[65] = 0;

Na realidade, a maioria das linguagens de programação fornece uma função de uma linha como crypto.randomUUID() para fazer tudo isso por você, garantindo que seja feito de forma correta e segura. O ponto principal é que um UUID v4 é apenas 122 bits de pura aleatoriedade, envoltos em 6 bits de metadados.

Histórias do mundo real

O Pesadelo da Fusão de Bancos de Dados

Duas startups, "Acme" e "WidgetCorp", decidiram se fundir. Ambas tinham produtos de sucesso, cada uma com seu próprio banco de dados de usuários, produtos e pedidos. Na primeira reunião de integração, um desenvolvedor júnior perguntou: "Como vamos fundir as tabelas de usuários? Meu usuário com ID 101 é a 'Alice', mas o usuário deles com ID 101 é o 'Bob'." A sala ficou em silêncio. Todas as tabelas em ambos os bancos de dados usavam IDs de inteiros simples e auto-incrementáveis. Fundi-los seria uma tarefa monumental de reescrever foreign keys, cruzar referências de cada registro e rezar para que nada fosse esquecido. Isso atrasou a fusão em meses.

Lição: Se eles tivessem usado UUIDs desde o início, a fusão teria sido trivial. O usuário f47ac10b-58cc-4372-a567-0e02b2c3d479 da Acme poderia coexistir perfeitamente com o usuário 9c68a520-2a83-43a3-b45d-4c86518a28cc da WidgetCorp. Sem colisões, sem pesadelos. UUIDs são essenciais para sistemas que um dia possam precisar interagir ou se fundir.

O Carrinho de Compras Ligeirinho

Uma desenvolvedora estava construindo uma nova funcionalidade de "adição rápida" para um e-commerce. Quando um usuário clicava em "Adicionar ao Carrinho" em uma lista de produtos, um spinner aparecia por 1-2 segundos enquanto o aplicativo esperava o servidor criar o item no carrinho e retornar seu novo ID. A sensação era de lentidão. A desenvolvedora teve uma sacada genial: e se o aplicativo não esperasse? Ela mudou o código para que, quando o usuário clicasse, o navegador gerasse imediatamente um UUID v4 para o novo item do carrinho, o adicionasse ao estado local e atualizasse a UI instantaneamente. O aplicativo parecia extremamente rápido. Nos bastidores, ele enviava a requisição para o servidor, dizendo: "Por favor, crie um item de carrinho com este UUID específico." Se a rede falhasse, o aplicativo poderia simplesmente tentar novamente mais tarde, usando o mesmo UUID para evitar a criação de itens duplicados.

Lição: A geração de UUIDs no lado do cliente (client-side) possibilita a "UI Otimista" (Optimistic UI), onde a interface é atualizada imediatamente, assumindo que a operação será bem-sucedida. Isso cria uma experiência de usuário muito mais rápida e responsiva e torna o tratamento de cenários offline muito mais simples.

A História de Detetive dos Microserviços

Um cliente relatou um erro: seu pedido falhou, mas seu cartão ainda foi cobrado. O sistema era uma teia complexa de microservices: Auth, Gateway, Orders, Payments, Shipping. Uma única requisição podia passar por cinco ou seis desses serviços. Encontrar o ponto exato da falha era como procurar uma agulha num palheiro de um milhão de entradas de log por minuto. O arquiteto líder determinou uma mudança: cada requisição de entrada no Gateway receberia um UUID, chamado de "ID de Correlação" (Correlation ID). Esse ID seria passado para todos os microservices que lidassem com a requisição, e cada mensagem de log o incluiria. Na próxima vez que um erro ocorreu, a equipe de suporte simplesmente pesquisou no sistema de logs por aquele único UUID. Instantaneamente, eles tinham uma história completa e cronológica da jornada da requisição por todo o sistema, identificando o serviço exato que falhou.

Lição: UUIDs são inestimáveis como IDs de correlação para rastrear requisições e depurar em arquiteturas distribuídas e baseadas em microservices.

Erros comuns e armadilhas

  • Usar UUIDs como chaves primárias de banco de dados... de forma descuidada. Embora ótimos para unicidade, UUIDs são grandes (16 bytes vs. 4 ou 8 para um inteiro) e aleatórios. A aleatoriedade pode ser terrível para a performance dos índices do banco de dados, levando à fragmentação e escritas mais lentas, pois o banco de dados tem dificuldade em inserir novas linhas no meio de uma árvore B de índice. Bancos de dados modernos e versões mais novas de UUID (como a proposta v7, que é ordenada por tempo) podem mitigar isso, mas é um trade-off crítico a se ter em mente.
  • Assumir que todos os UUIDs são aleatórios. Um desenvolvedor pode ver um UUID em um sistema legado e criar lógica assumindo que ele é imprevisível. Ele pode não perceber que é um UUID v1, que contém um timestamp e o endereço MAC da máquina que o gerou, potencialmente vazando informações sensíveis.
  • Tratá-lo como uma string qualquer. Alguns desenvolvedores podem pensar que qualquer string única é um "UUID". Eles podem usar "product-123" ou gerar um ID com um gerador de números aleatórios fraco. UUIDs verdadeiros seguem um formato estrito e, para a v4, devem ser gerados com uma fonte de aleatoriedade criptograficamente segura para garantir a unicidade.
  • Usar a versão errada para a tarefa. Um erro comum é usar um UUID v4 (aleatório) quando você precisa de um determinístico. Por exemplo, se você precisa gerar um ID único para um arquivo com base em seu conteúdo, você deve usar um UUID v5 com o hash do arquivo como o "nome". Isso garante que, se você encontrar o mesmo arquivo novamente, gerará exatamente o mesmo UUID, permitindo uma desduplicação fácil.

Por que isso deve estar no seu radar

Você deve recorrer a um gerador de UUID sempre que estiver em uma situação em que:

  • Você precisa criar um identificador único, mas não pode depender de uma autoridade central (como uma única sequência de banco de dados).
  • Você está construindo um sistema distribuído, um microservice, ou qualquer aplicativo onde múltiplas instâncias precisam criar dados de forma independente.
  • Você quer gerar IDs únicos no lado do cliente (em um navegador ou aplicativo móvel) para atualizações de UI otimistas ou capacidades offline.
  • Você precisa criar IDs de correlação para rastrear requisições enquanto elas fluem por múltiplos sistemas.
  • Você está escolhendo uma chave primária (primary key) para uma tabela de banco de dados e prioriza a unicidade global em detrimento da performance bruta de inserção (e você considerou os trade-offs).

No desenvolvimento de software moderno, esses cenários são a regra, não a exceção. Saber quando e como usar UUIDs é uma habilidade fundamental.

Para ir mais fundo

Teoria feita. Hora de pôr a mão na massa — 100% no seu navegador.

Testar a ferramenta: Gerador de UUID