Databázová sekvencia spoľahlivo pridelí ďalšie číslo, ak všetky zápisy prechádzajú jedným miestom. Moderný systém však vytvára objekty v mobilnej aplikácii, viacerých regiónoch, importe a samostatných službách. UUID poskytuje identitu bez prvého round tripu k centrálnemu čítaču. Používa 128-bitový priestor a presne definovaný spôsob generovania, vďaka čomu je kolízia pri správnej implementácii mimoriadne nepravdepodobná.

Veľký priestor nahrádza prideľovateľa

UUID sa zvyčajne zapisuje ako 32 hex číslic s pomlčkami. Časť bitov označuje verziu a variant, zvyšok obsahuje náhodné, časové alebo name-based dáta.

Unikátnosť nie je matematická nemožnosť kolízie. Je to praktická vlastnosť veľkého priestoru a kvalitného generátora. Databázový unique constraint zostáva povinný.

ID môže vzniknúť pred uložením

Offline klient vytvorí dokument, odkáže naň z ďalších lokálnych zmien a celý graf neskôr synchronizuje. Producent správy vytvorí command ID pred publikáciou a používa ho v tracingu.

Pri zlúčení databáz sa sekvenčné hodnoty 42 stretnú, zatiaľ čo UUID obyčajne zostanú bez premapovania vzťahov.

Verzia opisuje zdroj bitov

V4 je prevažne náhodná, v7 kombinuje čas v milisekundách s náhodnosťou a name-based verzie vytvoria rovnaké ID pre rovnaký namespace a meno. Výber ovplyvňuje poradie, súkromie a index.

Validná syntax nedokazuje existenciu objektu ani dôveryhodného pôvodcu. UUID je identifikátor, nie podpis či credential.

Kolízia sa musí bezpečne skončiť

Unique constraint zachytí extrémne vzácny stret aj oveľa pravdepodobnejšiu chybu generátora, fixture alebo opakovaného použitia hodnoty. Create operácia môže pri skutočne novom objekte vygenerovať nové ID.

Rovnaké ID s odlišným requestom však môže znamenať porušenie idempotency kontraktu. Nemá sa automaticky prepísať.

Text je reprezentácia, nie databázový typ

V URL a JSON je kanonický text praktický. V databáze je kompaktnejší natívny UUID typ alebo 16 bajtov. Všetky služby musia používať rovnaký byte order.

Parser má byť štandardná knižnica. Ručné odstraňovanie pomlčiek a delenie substringov vytvára chyby verzie a variantu.

UUID znižuje odhadnuteľnosť, nie potrebu autorizácie

Náhodná hodnota nesprístupní susedné záznamy tak ľahko ako sekvencia. Odkaz však môže uniknúť z logu, browser history alebo správy.

Každý request kontroluje oprávnenie k objektu. Ak samotný odkaz udeľuje prístup, potrebuje samostatný capability token s expiráciou.

Retry potrebuje stabilnú identitu

Ak klient po timeoute zopakuje rovnakú create operáciu s rovnakým UUID, server môže vrátiť pôvodný výsledok. Nové ID pri každom pokuse vytvorí duplikáty.

API musí určiť, či ID vytvára klient alebo server. Gateway a backend ho nesmú dopĺňať rozdielne podľa cesty requestu.

Poradie ID nie je automaticky poradie udalostí

V4 je náhodná. V7 sa približne radí podľa času, no uzly majú odlišné hodiny a viac udalostí vznikne v rovnakej milisekunde.

Doménové poradie používa sequence, aggregate version alebo broker offset. ID má primárne pomenovať objekt.

Generátor je bezpečnostná a prevádzková závislosť

V4 potrebuje kvalitný random source. Klonovaný VM stav alebo chybná embedded implementácia môže znížiť entropiu. Organizácia má používať udržiavanú systémovú knižnicu, nie vlastný algoritmus.

Monitoring konfliktov nemá predpokladať nemožnosť. Jeden konflikt môže odhaliť vážnu chybu deploymentu a vyžaduje vyšetrovanie.

Import potrebuje zachovať pôvodnú identitu

Pri migrácii možno UUID preniesť bez zmeny, ak cieľová doména uznáva rovnaký objekt. Ak sa importovaný záznam stáva novým objektom, môže dostať nové ID a mapovaciu tabuľku.

Rozhodnutie ovplyvňuje eventy, cache a externé odkazy. Nemá vzniknúť náhodne podľa toho, ktorá vrstva import vykonala.

Hodnota UUID je odstránenie koordinačného bodu

Služby a klienti môžu vytvárať identity samostatne a neskôr bezpečne spájať dáta. Cena je dlhšia reprezentácia a možné náklady indexu.

Štandardný generátor, unique constraint, kanonický prenos a autorizácia robia z UUID spoľahlivý stavebný prvok. Nie je to mágia, ale praktický kompromis pre distribuovanú identitu.

Offline merge potrebuje viac než iba unikátne ID

UUID zabráni tomu, aby dva klienti náhodne pomenovali rozdielne objekty rovnakým lokálnym číslom. Nevyrieši konflikt, keď oba editujú ten istý objekt. Synchronizácia stále potrebuje verziu, vector clock, last-write policy alebo doménové zlúčenie polí.

Identita určí, ktoré zmeny patria k sebe. Samostatný conflict model rozhodne, ktorá hodnota prežije. Zameniť tieto dve úlohy vedie k tichému prepisovaniu údajov.

Event a objekt nemusia zdieľať ID

Objekt má stabilnú identitu počas celého života, zatiaľ čo každý event opisujúci jeho zmenu potrebuje vlastné event ID. Retry toho istého eventu zachová event ID, nová zmena vytvorí nové. Aggregate ID zostáva rovnaké.

Toto rozlíšenie pomáha deduplikácii message brokera, auditu aj replay. Použiť object UUID ako ID každej správy by spôsobilo, že legitímne ďalšie udalosti vyzerajú ako duplicity.

Tracing využíva identitu ešte pred databázou

Request alebo command UUID možno vložiť do logu, trace a queue message na začiatku workflow. Všetky služby potom spájajú kroky bez čakania na databázové auto-increment ID.

Correlation ID však nemá automaticky prejsť do verejnej identity objektu. Má kratší lifecycle a môže odhaliť internú topológiu. Každá rola identifikátora potrebuje samostatný názov.

Pri zmazaní objektu sa UUID obyčajne znovu neprideľuje. Opätovné použitie starej verejnej adresy by mohlo spojiť historické odkazy, cache a audit s novým nesúvisiacim obsahom. Tombstone alebo permanentná rezervácia identity zachová význam aj po fyzickom cleanup-e. Retenčná politika môže odstrániť citlivé dáta, ale nemá dovoliť, aby rovnaký identifikátor začal označovať iný subjekt.

Toto pravidlo platí rovnako pre importované aj lokálne vytvorené objekty.