UUIDs vereinfachen die Vergabe verteilter Identitäten, doch rund um die 128 Bits entstehen weiterhin klassische Designfehler. Eine beliebige Textspalte akzeptiert ungültige Formen, zufällige Primärschlüssel verändern Indexverhalten, Retries erzeugen neue Geschäftsobjekte und APIs behandeln schwer erratbare IDs wie Berechtigungen. Das Format ersetzt weder ein sauberes Schema noch einen klaren Lebenszyklus.

Ein allgemeines Textfeld verliert Struktur

VARCHAR(255) speichert UUIDs, erlaubt aber auch Leerzeichen, abgeschnittene Werte und uneinheitliche Schreibweisen. Indexe werden größer als nötig. Native UUID-Typen oder 16-Byte-Felder validieren Struktur und speichern kompakter.

Wenn Text aus Kompatibilitätsgründen nötig ist, sollte Länge und kanonische Form eingeschränkt werden. Normalisierung gehört an die Eingabegrenze, nicht in jede Query.

Binärdarstellung braucht eine gemeinsame Byteordnung

Manche Systeme ordnen UUID-Bytes für bessere Indexlokalität um. Wird dieselbe Transformation bei Foreign Keys, Exporten oder in einem anderen Dienst nicht angewendet, sehen identische Textwerte intern verschieden aus.

Eine optimierte Darstellung muss dokumentiert und über zentrale Konverter verwendet werden. Native Datenbanktypen vermeiden viele solcher proprietären Entscheidungen.

Zufällige Primärschlüssel können Schreibkosten erhöhen

UUIDv4 verteilt Inserts über einen geordneten Index. Unter hoher Last entstehen mehr Page Splits und Cachebewegungen als bei monotonen Schlüsseln. Das ist keine pauschale Ablehnung von UUIDs, sondern eine messbare Eigenschaft.

UUIDv7, angepasste Indexe oder ein separater interner Schlüssel sind mögliche Antworten. Ein Benchmark sollte das echte Verhältnis von Reads, Writes und Joins abbilden.

Eine einfache Regex ist kein vollständiger Validator

Gruppen aus Hexzeichen zu prüfen erkennt nicht zwingend Variante und Version. Umgekehrt lehnt eine alte „nur v4“-Regex gültige v7-Werte ab. Bibliotheken können parsen und strukturierte Eigenschaften ausgeben.

Die Anwendung entscheidet anschließend, welche Versionen fachlich erlaubt sind. Zusätzliche Zeichen oder abgeschnittene Werte werden nicht still repariert, weil daraus eine andere Identität entstehen könnte.

UUID ist kein Autorisierungsmechanismus

Ein Endpoint, der allein bei Kenntnis der ID Daten liefert, setzt auf Unauffindbarkeit. IDs gelangen über Logs, Links und gemeinsame Geräte nach außen. Jeder Zugriff muss Benutzer, Tenant und Aktion prüfen.

Capability-Links verwenden einen separaten zufälligen Token mit Ablauf und Widerruf. Die UUID kann das Objekt identifizieren, ohne selbst das Zugriffsrecht zu sein.

Retries brauchen dieselbe fachliche Identität

Erzeugt der Client bei jedem Versuch eine neue UUID, kann ein Timeout mehrere Datensätze erzeugen. Eine Unique Constraint verhindert nur dieselbe ID, nicht dieselbe Bestellung oder Zahlung.

Der Client sollte die Objekt-ID oder einen Idempotency-Key für alle Wiederholungen behalten. Der Server verknüpft Schlüssel und Request-Inhalt und liefert bei einem Retry das frühere Ergebnis.

Interne und öffentliche IDs werden leicht verwechselt

Ein Modell mit Integer-Primärschlüssel und öffentlicher UUID kann sinnvoll sein, erzeugt aber zwei Identitäten. Routes, DTOs und Repositorymethoden müssen im Namen zeigen, welche erwartet wird. Sonst findet eine Query das falsche Objekt oder umgeht einen Scope.

Serialisierer sollten interne IDs nicht versehentlich ausgeben. Tests an der API-Grenze schützen den öffentlichen Vertrag.

Foreign Keys müssen denselben Typ verwenden

Eine binäre Primary UUID und textuelle Foreign UUID erschweren Constraints und Joins. Länge, Collation und Transformation müssen in allen Tabellen übereinstimmen. Ohne echte Foreign Keys sammeln sich verwaiste Referenzen.

Migrationen sollten Schema und Daten gemeinsam prüfen. Ein korrekter Textwert hilft nicht, wenn seine Byteordnung in der Zieltabelle anders interpretiert wird.

Bulk-Endpoints verstärken kleine Fehler

Eine Liste aus Tausenden gültigen UUIDs kann eine teure Query und große Antwort erzeugen. Mengenlimits, Deduplizierung und passende Indexe gehören zur Schnittstelle. Jede Ressource muss weiterhin im erlaubten Tenant liegen.

Die Antwort sollte nicht verraten, welche fremden IDs existieren. Fehlermodell und Autorisierung müssen auch bei Sammeloperationen konsistent bleiben.

Serialisierung behandelt UUID als opaken String

JSON besitzt keinen UUID-Typ, daher reist die kanonische Textform. Clients sollten sie nicht in Zahlen zerlegen oder Großschreibung als fachliche Information verwenden. Queue, Cache und Logs müssen den vollständigen Wert erhalten.

Supporttools dürfen Kontext anzeigen, sollten aber exaktes Kopieren und Suchen ermöglichen. Gekürzte Anzeige ist für Menschen praktisch, reicht nicht als eindeutiger Schlüssel.

Importe brauchen ein persistentes Mapping

Bei jeder Ausführung neue IDs zu generieren bricht Wiederholbarkeit und Beziehungen. Eine Mapping-Tabelle aus Quelle, externer ID und interner UUID hält die Zuordnung über mehrere Läufe stabil.

Sie ermöglicht außerdem Konfliktprüfung und Audit. Deterministische namenskodierte UUIDs können eine Alternative sein, wenn Namespace und Normalisierung dauerhaft feststehen.

Seltene Duplicate-Fehler sind ein Alarmsignal

Eine echte zufällige Kollision ist extrem unwahrscheinlich. Ein Duplicate kann stattdessen einen kaputten Generator, kopierten Testzustand oder falsch implementierten Retry anzeigen. Version, Bibliothek, Host und Request-ID helfen bei der Untersuchung.

Blind eine neue UUID zu würfeln kann den Symptomfehler verbergen und ein fachliches Duplikat erzeugen. Der Ursprung sollte sichtbar bleiben.

API-Fehler brauchen stabile Kategorien

Eine syntaktisch ungültige UUID sollte vor der Datenbankabfrage als fehlerhafte Eingabe erkannt werden. „Nicht gefunden“ und „nicht berechtigt“ können nach außen bewusst gleich aussehen, während interne Telemetrie die Ursache unterscheidet. So vermeidet die API Enumeration und bleibt trotzdem untersuchbar.

Metriken zu ungültigen Versionen, ungewöhnlichen Duplikaten und fehlgeschlagenen Lookups zeigen kaputte Clients oder automatisierte Scans. Der vollständige Wert muss dafür nicht in jedes Log kopiert werden; Request-ID und sicherer Fingerprint reichen häufig zur Korrelation.

Gemeinsame Governance verhindert inkompatible Inseln

Alle Dienste müssen wissen, wer IDs erzeugt, welche Version gilt, wann eine ID dauerhaft wird und welche Formen akzeptiert werden. Koordinationsfreie Erzeugung bedeutet nicht, dass kein gemeinsamer Vertrag nötig ist.

UUID funktioniert zuverlässig mit präzisem Storage, gemessenen Indexen, idempotenten Retries und expliziter Autorisierung. Die ID löst das Vergabeproblem; gute Systemgestaltung löst alles rundherum.