Gerador TSID (Time-Sorted ID)

TSID e TLID: o ID de 64 bits ordenado por tempo

TSID significa Time-Sorted Identifier e TLID, Time-Locked Identifier — um identificador de 64 bits projetado pelo desenvolvedor brasileiro Caio Gondim, lançado originalmente como a biblioteca Java tsid-creator em 2020. É uma alternativa propositalmente menor ao Twitter Snowflake e muito menor ao UUID, mantendo unicidade global, ordenação por tempo e ótima compatibilidade com bancos relacionais.

Layout de bits

Os 64 bits são divididos em 42 bits de timestamp (milissegundos desde um epoch customizado) e 22 bits de aleatoriedade ou node + contador. O valor inteiro cabe em um BIGINT SQL, então PostgreSQL, MySQL, SQL Server e SQLite armazenam nativamente — sem precisar de uma coluna uuid dedicada.

| 42 bits tempo (ms)            | 22 bits random / node-counter |
+-------------------------------+-------------------------------+

A forma textual canônica tem 13 caracteres em Crockford Base32 — URL-safe, case-insensitive, sem caracteres ambíguos (sem I, L, O, U). A variante TLID aplica embaralhamento/codificação adicional para que valores consecutivos não pareçam monotônicos — útil quando se quer indexação ordenada sem revelar a ordem de criação ao usuário final.

Por que TSID em vez de UUID ou Snowflake

• Menor que UUID — 64 bits contra 128 bits, metade do tamanho do índice e o dobro da densidade de cache.
• Ordenado por tempo — inserts B-tree sequenciais, ~2-3x mais rápidos que UUID v4 em escala.
• Sem coordenador — diferente do Snowflake, que precisa de um registro de worker-id, o TSID pode ser gerado só com aleatoriedade nos 22 bits inferiores.
• URL-safe — 13 chars em Crockford Base32 é mais curto que um UUID e mais amigável para humanos.
• Sem sequence no banco — cada nó gera independente, perfeito para microsserviços.

Comparação com outros esquemas de ID

• UUID v4 — 128 bits, totalmente aleatório, péssimo para localidade B-tree.
• UUID v7 — 128 bits, timestamp + random, ordenável mas ainda o dobro do tamanho.
• ULID — 128 bits, ideia similar à v7 mas mais antiga, usa Crockford Base32.
• Snowflake — 64 bits, contador centralizado, exige coordenação de worker-id.
• TSID — 64 bits, descentralizado, cauda aleatória, sem coordenador necessário.

Ecossistema e bibliotecas

A implementação de referência é o tsid-creator para Java, muito popular na comunidade Spring Boot — TSID é uma das contribuições brasileiras open source mais bem-sucedidas em backend. Existem ports para vários ecossistemas: tsid-rs (Rust), pgtsid (extensão PostgreSQL), implementações em JavaScript e Go, e wrappers para CLR/Kotlin. Armazene como BIGINT no Postgres e BIGINT UNSIGNED no MySQL.

Trade-offs a considerar

Com apenas 22 bits aleatórios por milissegundo, a entropia é muito menor que os 122 bits aleatórios do UUID v4. Para a maioria das cargas (milhões de IDs por segundo em uma frota) está ótimo, mas para identificadores sensíveis à segurança — tokens de reset de senha, IDs de sessão, qualquer coisa que um atacante possa tentar enumerar — prefira UUID v4 ou um token de CSPRNG dedicado. TSID é para chaves primárias, não para segredos.

Perguntas frequentes

TSID substitui UUID? Sim, em escala grande TSID é uma substituição forte para UUID v4 como chave primária quando você precisa de IDs compactos, ordenáveis por tempo, e cabe em uma coluna BIGINT.

TSID é menor que UUID v7? Sim — 64 bits contra 128 bits. Metade do tamanho de índice, metade do payload de rede, metade da memória.

Quando NÃO usar TSID? Quando precisa da máxima entropia para segurança (use UUID v4 ou CSPRNG), quando precisa seguir o tipo coluna UUID padrão para compatibilidade, ou quando 64 bits não serão suficientes para o ciclo de vida do sistema.

Qual a diferença entre TSID e TLID? TSID é o valor bruto ordenado por tempo. TLID adiciona uma etapa de codificação que esconde a ordenação monotônica da representação textual, então IDs consecutivos não parecem consecutivos.