SKID bietet ein mehrstufiges Identifikatorschema für verteilte Systeme, das Sortierbarkeit, Sicherheit und Zero-Lookup-Überprüfung kombiniert.
In verteilten Systemen ist ein Identifikator nicht nur ein Schlüssel in der Datenbank. Er spielt gleichzeitig eine Rolle bei der Indizierung, wird über die API übertragen und dient als Korrelations-Token. Das Problem tritt auf, wenn die Anforderungen in Konflikt geraten: B-Baum erfordert Ordnung, Sicherheit erfordert das Verbergen der Struktur, und Integrationen erfordern Überprüfbarkeit ohne zusätzliche Anfragen. Bestehende Ansätze – UUID v4/v7, Snowflake, ULID – decken einige Aufgaben ab, aber nicht alle gleichzeitig. Infolgedessen kommen Teams oft zu einem Dual-Identifier-Schema, bei dem eine ID in der Datenbank gespeichert wird und eine andere extern verwendet wird, was den Speicheraufwand erhöht und die Indizierung kompliziert.
SKID (Source Known Identifiers) bietet ein dreistufiges Modell, bei dem derselbe Identifikator über verschiedene Vertrauensgrenzen projiziert wird. Auf der Datenbankebene wird ein 64-Bit-SKID verwendet: Er umfasst einen Zeitstempel mit einer Genauigkeit von 250 ms, Anwendungs- und Instanzidentifikatoren sowie einen Sequenzzähler. Dies ergibt einen kompakten Primärschlüssel (8 Byte) und eine natürliche Sortierung für den B-Baum. Auf der Ebene der vertrauenswürdigen Umgebung wird dieselbe ID in einen 128-Bit-SKEID umgewandelt – einen UUID-kompatiblen Wert, dem der Entitätstyp, die Epoche und der BLAKE3 MAC hinzugefügt werden. Dieses Format ermöglicht die Validierung der Herkunft und Integrität ohne Zugriff auf die Datenbank (Zero-Lookup-Überprüfung). Für externe Kunden wird Secure SKEID verwendet – derselbe SKEID, aber vollständig über AES-256 verschlüsselt, was das Auslaufen von Metadaten verhindert.
Ein entscheidender ingenieurtechnischer Punkt sind die deterministischen Transformationen zwischen den Ebenen. SKID wird in der Datenbank gespeichert, während SKEID und Secure SKEID zur Laufzeit ohne I/O berechnet werden. Dies beseitigt die Notwendigkeit zusätzlicher Spalten und Indizes. Im Basisszenario, in dem normalerweise Auto-Increment-IDs, UUID und created_at verwendet werden, benötigt das System 32 Byte pro Eintrag und drei Indizes. SKID reduziert dies auf ein 8-Byte-Feld und einen Index, was eine Einsparung von bis zu 75 % auf der Speicherebene ermöglicht. Dabei bleibt die Sortierung erhalten, und der Zeitstempel ist bereits im Identifikator integriert.
In Bezug auf die Leistung wird die Architektur in drei Kostenschichten unterteilt. Die Generierung von SKID dauert etwa 35 ns dank einfacher Bit-Packing ohne Kryptografie. SKEID – etwa 230 ns, trotz der Hinzufügung von MAC, und ist schneller als UUID v7 (~377 ns). Secure SKEID – etwa 544 ns, was ungefähr 1,4-mal langsamer ist als UUID v7 aufgrund von AES-256. Dies ist ein klarer Trade-off: zusätzliche Sicherheit gegen Latenz bei der Generierung. Dennoch bleibt selbst die „schwerste“ Variante im Submikrosekundenbereich, was sie für Hochdurchsatzsysteme akzeptabel macht.
Ein interessanter Aspekt ist die Zero-Lookup-Überprüfung. In klassischen Systemen erfordert die Überprüfung von IDs den Zugriff auf die Datenbank oder den Cache. Hier enthält SKEID den BLAKE3 MAC, der es ermöglicht, die ID lokal zu validieren. Dies verringert die Belastung des Speichers und reduziert die Latenz bei verteilten Interaktionen. Allerdings ist der MAC auf 32 Bit gekürzt, was an sich keine starke Krypto-Sicherheit bietet. Die Lösung wird durch die Architektur der Verteidigung in der Tiefe kompensiert: Neben dem MAC werden AES-256, Marker-Bytes, die Überprüfung des Entitätstyps und sogar die Wahrscheinlichkeit des Vorhandenseins eines Eintrags verwendet. Ohne das Durchlaufen aller Ebenen wird ein Angriff nahezu unmöglich.
Besondere Aufmerksamkeit gilt dem Konflikt zwischen Sortierbarkeit und Vertraulichkeit. Zeitstempelbasierte Schemata offenbaren von Natur aus Muster der Generierung. SKID löst dies durch die Trennung der Ebenen: Innerhalb des Systems bleibt die ID geordnet, während nach außen eine verschlüsselte Form ausgegeben wird. So hat dieselbe Entität unterschiedliche Darstellungen, die an den Nutzungskontext angepasst sind, ohne Daten zu duplizieren.
Für die Industrie sieht dies wie eine pragmatische Alternative zum Dual-Identifier-Muster aus. Der Ansatz ist besonders nützlich in Systemen mit hoher Last (Highload), wo Effizienz der Indizes und Reduzierung von I/O wichtig sind. Er ist auch im API-Design anwendbar, wo eine sichere Veröffentlichung von Identifikatoren ohne Lecks erforderlich ist. Eine Einschränkung ist die Komplexität des kryptografischen Teils und die Notwendigkeit des Schlüsselmanagements (Key Rotation, Key-Ring). Dies erhöht die operationale Belastung, insbesondere für SRE- und DevOps-Teams.
Insgesamt ist SKID ein Beispiel dafür, wie architektonische Dekomposition entlang der Vertrauensgrenze inkompatible Anforderungen vereinen kann. Anstatt nach einer universellen ID zu suchen, wird ein System vorgeschlagen, bei dem ein Identifikator seine Form je nach Kontext ändert und dabei eine strenge Verbindung zwischen den Darstellungen aufrechterhält.
Informationsquelle
arXiv ist das größte offene Preprint‑Repository (seit 1991 unter der Schirmherrschaft der Cornell University), in dem Forschende schnell Arbeitsfassungen von Artikeln veröffentlichen; die Materialien sind öffentlich zugänglich, unterliegen jedoch keiner vollständigen Begutachtung, weshalb Ergebnisse als vorläufig angesehen und möglichst in überarbeiteten Versionen oder in begutachteten Fachzeitschriften überprüft werden sollten. arxiv.org