Виклик стандартної UUID-функції здається завершеним архітектурним рішенням, але version визначає важливу поведінку. Одні UUID випадкові, інші залежать від name, треті зберігають приблизний часовий порядок. Вони відрізняються privacy, repeatability, index performance і підтримкою платформ. Свідомий вибір не дозволяє зручному ID випадково стати джерелом витоку або database cost.

Version 4 є знайомим random default

UUID v4 заповнює більшість identifier випадковими бітами. Він широко підтримується, легко й безпечно генерується та не розкриває creation time або source name. Для публічних ID та distributed creation це сильний default, якщо ordering не потрібен.

Randomness розсіює вставки в ordered database index. На помірному масштабі це може не мати значення, але при великому write volume збільшує page splits і знижує locality. Вирішувати потрібно за workload, а не загальним правилом.

Time-based versions покращують ordering

Старий version 1 поєднує timestamp із node identifier. Він приблизно сортується за часом, але може розкрити момент створення й інформацію про generating node. Для public identifier це іноді небажано.

Version 7 розміщує Unix timestamp у сучасному time-ordered layout і додає randomness. Він покращує natural sorting та index locality без hardware address. Підтримка зростає, але всі producers, databases і clients повинні розуміти його до стандартизації.

Name-based UUID є детермінованим

Versions 3 і 5 виводять UUID із namespace UUID та name. Однакові inputs дають однаковий identifier, що корисно, коли кілька систем мають створити спільний ID без lookup service. Namespace не дозволяє однаковим names у різних доменах конфліктувати.

Inputs потрібно нормалізувати однаково: регістр, whitespace та encoding змінюють результат. Deterministic ID також може показати, що два записи походять з однакового source name, тому privacy слід оцінити окремо.

Не створюйте власну «версію UUID» без потреби

Саморобний bit layout або генератор руйнує interoperability та можливість аналізувати властивості стандарту. Якщо системі потрібен інший identifier, зрозуміліше вибрати іншу established scheme, а не створювати UUID-shaped string із приватними правилами.

Використовуйте maintained library із secure randomness і тестуйте очікувані version bits. Timestamp, process ID або звичайний pseudo-random function можуть повторювати значення під concurrency та cloned environment.

Sortability не є надійною хронологією

Time-ordered UUID допомагає index і приблизному сортуванню, але embedded time походить із machine clock. Годинник drift-ить, може піти назад, а concurrent generators створюють значення в одному interval. Не використовуйте порядок UUID як єдину юридичну або фінансову chronology.

Зберігайте explicit creation timestamp і domain-specific sequence там, де порядок критичний. Identifier order є optimization, а не повною event model.

Migration потребує compatibility plan

Зміна preferred version не змінює загальну textual форму, але assumptions можуть існувати у validators, sorting, tests та clients. Одні системи відхиляють незнайомий version, інші мовчки залежать від randomness або time order.

API має документувати accepted versions окремо від generated version. Сервіс може приймати кілька стандартних versions, але створювати лише один для нових records.

Враховуйте всю екосистему

ID проходить через database, logs, queues, URLs, analytics і support tools. Переконайтеся, що кожна мова та платформа може parse і preserve обраний version. Операційні інструменти повинні дозволяти exact search без припущення про sequential value.

Time-ordered ID спрощує візуальне сортування, random — не показує приблизний порядок створення. Це частина privacy та observability trade-off.

Вибір потрібно зафіксувати як стандарт системи

Version policy має враховувати зовнішні інтеграції

Партнерський API може приймати будь-який UUID або вимагати конкретний version. Якщо система генерує v7, а зовнішній validator застаріло приймає лише v4, інтеграція зламається, хоча обидва значення стандартні. Compatibility потрібно перевірити до rollout.

На вхідній межі відділяйте syntactic validity від business policy. Це дозволяє повертати зрозумілу помилку й поступово розширювати accepted versions.

Privacy залежить не лише від version

Random UUID не розкриває creation time, але API навколо нього може показувати послідовність, count або зв’язки. Time-ordered ID розкриває приблизний момент створення, що іноді є прийнятним для internal data й небажаним для public resources.

Threat model повинен оцінювати весь endpoint. Зміна version не виправляє overexposed response або відсутню authorization.

Operational migration не повинна переписувати references

Після переходу на новий preferred version старі IDs зазвичай залишаються валідними назавжди. Масове перепризначення створює ризик broken links, foreign keys та external references. Новий generator варто застосовувати лише до нових records.

Validators і clients повинні підтримувати змішаний період. Metrics accepted versions допомагають розуміти реальний стан даних.

Вибір потрібно зафіксувати як стандарт системи

Benchmark має відображати реальну схему

Порівняння UUID versions лише на швидкості генерації майже нічого не говорить про систему. Вимірюйте insertion rate, index size, join performance, replication і поведінку backup на production-shaped data.

Результат залежить від database engine, page size та access pattern. Рекомендація з іншого проєкту може не відповідати вашому workload.

Перед остаточним вибором корисно провести невеликий rollout на окремій таблиці або частині трафіку. Так команда побачить не лише синтетичні цифри, а й вплив на повільні запити, обсяг індексів та щоденну роботу операторів.

Version 4 підходить для random ID із широкою підтримкою, version 7 — коли важливі time ordering і write locality, name-based — для deterministic mapping. Рішення варто записати в architecture docs і надати одну shared generation convention.

Existing identifiers залишаються довговічними references навіть після зміни preferred version. Міграція не повинна переписувати їх без сильної причини.