Validador de ObjectId Genérico

ObjectId do MongoDB: o identificador BSON de 12 bytes e ordenável por tempo por trás de todo _id

ObjectId é o tipo padrão de chave primária para documentos no MongoDB. Definido pela especificação BSON, é um valor de 12 bytes (96 bits) representado como uma string hexadecimal de 24 caracteres. Um exemplo canônico é 507f191e810c19729de860ea — todo documento MongoDB recebe um automaticamente em seu campo _id, a menos que você sobrescreva.

Os 12 bytes são estruturados em três segmentos com significado próprio, o que dá ao ObjectId suas propriedades distintivas: aproximadamente ordenável no tempo, gerável em qualquer cliente sem coordenação e compacto o bastante para usar como slug de URL quando discrição não é problema.

Anatomia de um ObjectId — 12 bytes, 3 campos

• 4 bytes — timestamp: segundos desde o Unix epoch (granularidade é em segundos, não milissegundos).
• 5 bytes — valor aleatório por processo: gerado uma única vez na inicialização do processo e reutilizado para cada ObjectId criado por ele.
• 3 bytes — contador incremental: começa em um valor aleatório e incrementa para cada novo ObjectId dentro do processo.

Antes da revisão de spec de 2018, o segmento do meio era 3 bytes de identificador de máquina + 2 bytes de PID. Isso foi substituído porque o PID e a impressão digital da máquina vazavam informação operacional sobre a topologia do deploy. O valor aleatório de 5 bytes atual mantém a ordenabilidade temporal sem o vazamento.

Ordenabilidade e extração de timestamp

Como o timestamp fica nos bytes mais significativos, ObjectIds ordenam lexicograficamente em ordem cronológica aproximada. Isso barateia consultas do tipo "listar do mais novo para o mais antigo" mesmo quando só há índice por _id. O driver MongoDB expõe new ObjectId(str).getTimestamp(), que devolve um Date JavaScript construído a partir dos 4 primeiros bytes:

const id = new ObjectId('507f191e810c19729de860ea');
id.getTimestamp(); // 2012-10-17T20:46:22.000Z

ObjectId vs UUID, UUID v7 e ULID

• vs UUID v4: ObjectId é mais curto (24 vs 36 chars) e ordenável no tempo, mas oferece menos entropia (96 vs 128 bits) e não é padronizado fora do MongoDB.
• vs UUID v7: similar em espírito — ambos prefixam timestamp para ordenabilidade — mas UUID v7 é RFC 9562 (2024) e usa 128 bits com precisão de milissegundos.
• vs ULID: 128 bits codificados em Crockford Base32 de 26 caracteres. Mais entropia que ObjectId, mais compacto que UUID, também ordenável no tempo.
• Clock drift: todos os IDs com prefixo de timestamp dependem de relógios de sistema acurados. Sincronização NTP é inegociável num cluster.

Armadilhas, segurança e uso em produção no Brasil

• Granularidade de segundos: dois ObjectIds gerados no mesmo segundo podem ordenar fora de sequência — ok para agrupamento cronológico, não para ordenação estrita de eventos.
• Antifraude / IDOR: nunca use ObjectIds como URL pública de recursos sensíveis. O prefixo de timestamp vaza horário de criação e o contador vaza volume.
• String vs BSON: ObjectIds podem ser armazenados como BSON nativo ou como string hex de 24 chars. Misturar representações em consultas causa misses silenciosos.
• Stack de e-commerce brasileiro: empresas como B2W, Magalu e iFood usam MongoDB em partes da arquitetura (junto com Postgres e DynamoDB), então o ObjectId aparece em várias bases backend do BR.
• Atlas: o cloud gerenciado da MongoDB (MongoDB Atlas) gera e valida ObjectIds da mesma forma que um cluster self-hosted — não há diferença comportamental.

Regex de validação e helpers de biblioteca

Uma regex estrita para a forma em string hex é ^[a-fA-F0-9]{24}$. Combine com o ObjectId.isValid() oficial ao aceitar entrada de clientes, porque o isValid() sozinho retorna true para qualquer string ASCII de 12 caracteres, além das strings de 24 hex.

FAQ

Um ObjectId tem 12 ou 24 caracteres?

Os dois, dependendo da representação: 12 bytes em BSON binário cru, 24 caracteres quando serializado em hexadecimal (cada byte = 2 dígitos hex). A forma de 24 hex é a que aparece em APIs JSON e URLs.

ObjectIds são ordenáveis?

Sim — aproximadamente em ordem cronológica. O timestamp de 4 bytes é a parte mais significativa, então ordenação lexicográfica na string hex coloca documentos mais antigos primeiro. A granularidade é de um segundo, então IDs gerados no mesmo segundo podem não estar perfeitamente ordenados.

Posso extrair o timestamp de criação?

Sim. Os primeiros 4 bytes são um timestamp Unix em segundos. Drivers expõem um helper como new ObjectId(str).getTimestamp() que retorna um objeto Date. Você também pode decodificar à mão: parseInt(hex.slice(0,8), 16) devolve os segundos Unix.

Por que o MongoDB removeu a estrutura de machine ID + PID?

A revisão de spec de 2018 trocou o antigo identificador de máquina de 3 bytes + PID de 2 bytes por um valor aleatório por processo de 5 bytes. A mudança fechou um vetor de vazamento de informação — os campos originais expunham detalhes operacionais (hostnames, PIDs) que podiam ajudar um atacante.

Devo usar ObjectId ou UUID v7 num projeto novo?

Se você vive no ecossistema MongoDB, ObjectId é o caminho de menor resistência — é padrão e todo driver suporta nativamente. Para portabilidade entre bancos, precisão em milissegundos ou entropia maior, escolha UUID v7 (RFC 9562, 2024) ou ULID.