Gerador Snowflake Instagram

IDs do Instagram: fork do Snowflake para Postgres sharded

O Instagram migrou de chaves primárias auto-incremento do Postgres para um ID estilo Snowflake de 64 bits em 2012, depois que a empresa fragmentou sua frota de banco de dados. O post de Mike Krieger no blog de engenharia daquele ano ainda é a referência canônica — descreve como o time precisava de IDs globalmente únicos, ordenados por tempo, que coubessem em um BIGINT SQL e, criticamente, codificassem o shard lógico para que o ID pudesse ser roteado de volta ao seu nó Postgres sem tabela de lookup.

Layout de bits usado pelo Instagram

 41 bits        | 13 bits     | 10 bits
 timestamp ms   | shard id    | sequência por shard
 desde 2011-08  | (0-8191)    | (0-1023)

O epoch do Instagram é 1314220021721 (24 de agosto de 2011). Para decodificar um ID de mídia de volta ao seu horário de criação: unix_ms = (snowflake >> 22) + 1314220021721. Treze bits de shard permitem 8.192 shards lógicos — o Instagram pré-alocou mais shards que máquinas físicas para poder rebalancear depois. A sequência de 10 bits permite 1.024 IDs por milissegundo por shard, o que combina confortavelmente com o throughput de um único nó Postgres.

Shortcodes, Reels, Stories e Threads

• Shortcode da URL — o que aparece em instagram.com/p/<shortcode> é uma codificação estilo base64 do BIGINT. Conversores da comunidade fazem o round-trip shortcode ↔ ID ↔ timestamp.
• IDs de Story / Reel — mesma forma de 64 bits, alocação interna de sub-bits diferente conforme a superfície.
• Threads (Meta, 2023) — roda no mesmo backend do Instagram, então IDs de post seguem a mesma estrutura estilo Snowflake.
• Comparação — Twitter Snowflake = 41 ts + 5 datacenter + 5 worker + 12 sequência. Discord = 42 ts + 5 dc + 5 worker + 12 sequência com epoch 1420070400000. O Instagram troca datacenter/worker pelo shard ID lógico.

Por que gerar IDs Instagram mock?

IDs com forma realista são úteis para popular bancos de teste, mockar respostas da Graph API, validar migrações de schema, montar dashboards de demonstração e testar lógica de detecção de scraping. A Meta nunca documentou oficialmente o layout exato de bits — a estrutura acima foi engenharia reversa da comunidade, confirmada empiricamente decodificando milhões de IDs públicos.

Ângulo de privacidade e forense

Como o ID embute o timestamp de criação, todo post do Instagram vaza o milissegundo exato em que foi criado — útil para OSINT e forense, problemático para privacidade. Datas de criação de conta e cadência de postagem viram trivialmente extraíveis de qualquer perfil público, o que é uma das razões pelas quais a Meta empurra integrações para a Graph API em vez de scraping de HTML.

Perguntas frequentes

Posso extrair a data de criação de um post real do Instagram? Sim — desloque o ID 22 bits para a direita e some o epoch do Instagram 1314220021721. O resultado é o milissegundo Unix em que o post foi criado.

Scraping de IDs do Instagram é legal? Os Termos de Serviço da Meta proíbem scraping não autorizado. Para integrações em produção, use os endpoints oficiais da Instagram Graph API. Os IDs em si são públicos, mas a forma como você os obtém importa.

Os IDs mock colidem com os reais? Estatisticamente possível, mas extremamente improvável. Os IDs são válidos em forma, não registrados na Meta — existem apenas dentro do seu banco de testes.

Como isso difere do Snowflake do Twitter? O Twitter usa 5 bits para datacenter e 5 para worker (10 bits de identidade de máquina). O Instagram troca esses 10 bits por 13 bits de shard ID lógico e reduz a sequência para 10 bits — trocando throughput por granularidade fina de shard.