Decyzja „używamy UUID” nie określa jeszcze właściwości identyfikatora. Poszczególne wersje inaczej rozmieszczają 128 bitów. UUIDv4 jest losowym i dobrze znanym defaultem, UUIDv7 zapewnia przybliżoną kolejność czasu, a wersje name-based pozwalają odtworzyć tę samą wartość z namespace i nazwy. Wybór powinien wynikać z dostępu do danych, prywatności i kompatybilności.

UUIDv4 jest prostym losowym wyborem

Version 4 używa prawie całej przestrzeni na randomness. Nie ujawnia czasu utworzenia i może być generowana na każdym hoście. Systemowe biblioteki czynią ją łatwą oraz interoperacyjną.

Losowy rozkład wpływa na uporządkowane indeksy. Przy umiarkowanym ruchu bywa bez znaczenia, ale intensywne inserty wymagają pomiaru.

UUIDv7 łączy timestamp i losowość

Version 7 zaczyna się od unixowego czasu w milisekundach, a dalsze bity zapewniają uniqueness. Nowsze wartości trafiają zwykle za starsze, co poprawia locality B-tree i pomaga w operacyjnym sortowaniu.

Przybliżony czas utworzenia staje się widoczny. Dla wewnętrznych eventów to zaleta, dla poufnych publicznych obiektów może być metadata leak.

V7 nie jest globalną sekwencją

Wiele generatorów może działać w tej samej milisekundzie, a zegar cofnąć się. Biblioteka może zapewniać lokalną monotoniczność, ale nie tworzy transakcyjnego porządku wszystkich usług.

Luki, kolejność przyczynowa i dokładny numer wymagają sekwencji, log offsetu lub koordynacji. UUID nie powinien udawać mocniejszej gwarancji.

Name-based daje powtarzalne mapowanie

UUIDv5 i nowsze warianty deterministyczne wyliczają ID z namespace oraz name. Ten sam input daje ten sam wynik. Przydaje się to w importach, stałych rekordach i mapowaniu zewnętrznych kluczy.

Normalizacja jest częścią kontraktu. Wielkość liter, Unicode i whitespace muszą być ustalone przed obliczeniem, inaczej równoważne nazwy dadzą różne wartości.

Deterministyczny identyfikator nie ukrywa źródła

Jeżeli atakujący zna namespace i możliwe names, może sam obliczyć UUID. Taki wariant nie jest access tokenem ani dobrą metodą zasłaniania małych numerów.

Determinism jest zaletą mapowania, a nie mechanizmem poufności. Dla nieprzewidywalnej publicznej tożsamości lepsza jest losowość.

Starsze wersje mają inne kompromisy

UUIDv1 łączy czas z node information, historycznie często MAC address. Może ujawniać urządzenie oraz moment. Nowe biblioteki potrafią ograniczać ten wyciek, lecz istniejące dane wymagają świadomej interpretacji.

UUIDv6 układa podobne dane bardziej przyjaźnie dla indeksu. Dla nowego systemu v7 bywa prostsze, jeśli ekosystem je obsługuje.

Kompatybilność trzeba sprawdzić praktycznie

Stary regex lub SDK może akceptować tylko v4, mimo że baza przechowa dowolną UUID. Gateway, analytics i partnerzy również mogą niepotrzebnie ograniczać version bits.

Rollout v7 warto rozpocząć w jednej tabeli lub małej części ruchu. Metryki pokażą odrzucenia zanim zmiana obejmie całość.

Polityka generowania i akceptowania jest różna

Usługa może tworzyć nowe v7 i nadal przyjmować historyczne v4. Walidator „tylko nowa wersja” złamie stare linki i importy. Input policy wynika z rzeczywistego katalogu.

Output powinien być kanoniczny, a klient traktować wartość jako opaque, jeżeli version nie ma znaczenia biznesowego.

Prywatność ocenia cały endpoint

V4 lepiej ukrywa moment niż v7, lecz API może zwracać created_at albo sortować po czasie. W publicznym artykule takie dane nie są tajne, w zamówieniu mogą mieć znaczenie.

Threat model obejmuje zasób, pozostałe metadane i uprawnienia. Sama wersja UUID nie daje prywatności.

Benchmark musi używać prawdziwego schematu

Prędkość generatora rzadko jest bottleneckiem. Liczą się index size, insert, join, replication i cache. Native UUID, binary storage oraz kolejność bajtów wpływają na wynik.

Warto mierzyć także obsługę: wyszukiwanie w logach, sortowanie w panelu i kopiowanie. Najszybsza baza nie zawsze daje najlepszy system.

Migracja nie przepisuje istniejących kluczy

Zmiana primary keys dotyka foreign keys, events, cache i zewnętrzne linki. Korzyść nowej wersji niemal nigdy nie uzasadnia takiego ryzyka. Nowa polityka obejmuje przyszłe rekordy.

Testy powinny zawierać mieszaną populację v4 i v7. Rollback wraca do generowania v4, ale nie usuwa już opublikowanych v7.

Rollout powinien mierzyć zachowanie całego ekosystemu

Nową version można włączyć dla jednego typu zasobu albo niewielkiej części ruchu. Dashboard powinien grupować błędy po endpoint, SDK i partnerze. Dzięki temu validator zakładający v4 zostanie znaleziony przed pełnym wdrożeniem.

Serwer nadal przyjmuje historyczne wartości. Rollout zmienia generator, nie ważność istniejących referencji. Plan rollbacku musi zachować już wydane v7, bo mogły trafić do zewnętrznych systemów.

Widoczność czasu w v7 trzeba oceniać konkretnie

Timestamp może ujawnić przybliżony moment utworzenia i tempo aktywności. W publicznych numerach wrażliwego procesu może to być niepożądane. W wewnętrznych logach i dużej tabeli ta sama informacja poprawia diagnostykę oraz index locality.

Gdy potrzebne są obie właściwości, system może używać v7 wewnętrznie i osobnej losowej publicznej UUID. Dodatkowe mapowanie ma jednak koszt, więc powinno wynikać z threat modelu.

Version choice nie zastępuje biblioteki wysokiej jakości

Dwie implementacje v7 mogą różnie zachowywać się przy wielu generacjach w jednej milisekundzie lub cofnięciu zegara. Warto wybrać utrzymywaną bibliotekę, przetestować monotonicity expectations i zapisać jej wersję w dokumentacji technicznej.

Sam standard określa format, lecz operacyjne właściwości generatora wpływają na sortowanie i diagnozę. Upgrade biblioteki zasługuje na test kontraktowy.

Wybór kończy się wspólną konwencją

Zespół dokumentuje bibliotekę, version, storage i input policy. Niezależne generowanie nie oznacza, że każdy serwis może wybrać inny format.

V4 pasuje do losowych, czasowo nieprzezroczystych ID. V7 do index locality i przybliżonej kolejności. Name-based do powtarzalnego mapowania. Najlepsza wersja to ta, której cechy są rzeczywiście potrzebne.