La génération d’identifiants dans une application est un besoin métier très courant. Que ce soit pour créer des bons de commande, des utilisateurs ou toute autre entité métier, chaque objet a besoin d’un identifiant unique et traçable. Ce besoin devient crucial lorsque l’application commence à scaler horizontalement (multiplication des instances, microservices, etc.).
Dans une application classique, on utilise souvent des identifiants auto-incrémentés ou des UUID. Cependant, ces méthodes présentent des limites :
- Les identifiants incrémentaux sont hautement prévisibles (ce qui peut permettre, par exemple, d’estimer le nombre total de commandes ou d’accéder à des ressources non autorisées).
- Les UUID, bien qu’un peu plus sûrs, peuvent être trop longs, peu optimisés pour certaines bases de données, ou encore manquer de structure métier.
Une approche plus structurée et sécurisée devient donc nécessaire pour générer des identifiants robustes, non prévisibles et compatibles avec une architecture distribuée.
Les limites d’une approche classique
Auto-incrémentation
- Très prévisible : ces identifiants suivent un ordre strict et séquentiel, ce qui les rend facilement devinables. Un attaquant peut ainsi estimer le volume de données (nombre de commandes, d’utilisateurs, etc.), ou tenter des accès non autorisés par simple incrémentation.
UUID (notamment UUIDv4)
- Poids élevé : un UUIDv4 occupe 16 octets, contre 4 octets pour un entier auto-incrémenté (INT). Ce surcoût impacte :
- les performances de la base de données (indexation, tri, recherche)
- l’utilisation mémoire côté application, surtout à grande échelle
- Peu lisible et difficile à manipuler :
- les UUID sont longs, sans structure lisible et difficiles à interpréter pour un humain.
- ils compliquent le debug, l’affichage dans les interfaces, ou la construction d’URLs propres.
- ils ne portent aucune information métier (type d’entité, date de création, tenant, etc.).
- Risque (théorique) de collision :
- bien que rares, les collisions restent possibles si la source d’aléatoire est défaillante.
- même avec un espace d’identifiants très large (128 bits → 3.4 × 10³⁸ possibilités), une application à très haute volumétrie peut atteindre des seuils où ces risques deviennent réels.
Présentation du GID
Définition
Un Global ID (GID) est une représentation unique d’une entité dans une application. Il permet d’identifier de manière fiable et traçable n’importe quel objet métier (utilisateur, commande, document, etc.), tout en tenant compte du contexte du tenant (par exemple une organisation ou un client dans une application multi-tenant).
NB : un tenant représente une organisation ou un client dans une application multi-tenant (c’est-à-dire une application utilisée par plusieurs organisations).
Objectif et justification
Dans cet article, nous allons manipuler un GID de 24 octets. Ce format n’est pas un standard : la plupart des technologies utilisent plutôt 16 octets, tel que défini par les normes ISO/IEC 11578:1996, ITU-T Rec. X.667 et le RFC 4122 (spécification des UUID).
Nous faisons le choix d’un GID sur 24 octets (192 bits) pour répondre à des besoins spécifiques :
- garantir une unicité globale renforcée,
- inclure directement des informations métier (tenant, type d’entité, timestamp, etc.) dans la structure de l’identifiant.
- Optimiser pour le multi-tenant : éviter les jointures coûteuses pour identifier le tenant d’une entité
Concernant l’impact performance : bien que 24 octets soient plus lourds qu’un UUID standard (16 octets), les informations métier intégrées permettent d’éviter de nombreuses jointures SQL, compensant largement ce surcoût. De plus, l’indexation reste efficace grâce à la structure prévisible.
Anatomie du GID (explication binaire)
Notions de base
- Bit : la plus petite unité de données, représentant une valeur binaire (0 ou 1).
- Octet : un regroupement de 8 bits, suffisant pour représenter un caractère ou un élément de données complet.
En analogie :
- un bit est comme une lettre élémentaire
- un octet est le plus petit “mot” que l’ordinateur peut manipuler directement.
Donc :
- 2 octets = 16 bits (2 × 8)
- 8 octets = 64 bits (8 × 8)
- 24 octets = 192 bits (24 × 8)
Formule générale :
Cas pratique
Nous allons implémenter un GID de 24 octets avec Go, dans un système multi-tenant. Chaque bloc de l’identifiant se voit attribuer une plage précise pour reconstituer les 24 octets
| Octets | Contenu | Taille |
|---|---|---|
| 0-7 | Tenant ID | 8 octets (64 bits) |
| 8-9 | Entity Type | 2 octets (16 bits) |
| 10-17 | Timestamp | 8 octets (64 bits) |
| 18-23 | Random | 6 octets (48 bits) |
Ainsi, le GID contient à la fois des informations métier (tenant, type), un timestamp pour la traçabilité, et des données aléatoires pour garantir l’unicité globale.
1. Déclaration des variables
package gid
import (
"crypto/rand"
"encoding/binary"
"encoding/hex"
"fmt"
"strings"
"time"
)
const (
GIDSize = 24 // 192 bits au total
)
type (
GID [GIDSize]byte // GID = tableau de 24 octets
TenantID [8]byte // Tenant sur 8 octets
)
2. Initialisation du GID
package gid
func NewGID(tenantID TenantID, entityType uint16) {
var id GID // on initialise un tableau de 24 octets pour notre GID
}3. Séparation des blocs et construction
package gid
func NewGID(tenantID TenantID, entityType uint16) (GID, error) {
var id GID
// 1. Tenant ID (octets 0 à 7)
// On copie les 8 octets de tenantID dans les 8 premiers octets de id
copy(id[0:8], tenantID[:])
// 2. Entity Type (octets 8 à 9)
// - entityType est un uint16 (16 bits = 2 octets)
// - On l'encode en bytes Big Endian et on l'écrit dans id[8] et id[9]
binary.BigEndian.PutUint16(id[8:10], entityType)
// 3. Timestamp (octets 10 à 17)
// - On récupère le timestamp actuel en millisecondes
// - On le convertit en uint64 (64 bits = 8 octets)
// - On écrit ces 8 octets dans id[10] à id[17]
now := time.Now().UnixMilli()
binary.BigEndian.PutUint64(id[10:18], uint64(now))
// 4. Données aléatoires (octets 18 à 23)
// - Ces 6 octets servent à garantir l'unicité globale du GID
// - On les remplit avec des bytes aléatoires
_, err := rand.Read(id[18:24])
if err != nil {
return Nil, fmt.Errorf("failed to generate random bytes: %v", err)
}
return id, nil
}Avantages du GID
- Traçabilité native : timestamp intégré pour audit et debug
- Context-aware : tenant et type d’entité directement accessibles
- Performances : évite les jointures pour identifier le contexte
- Sécurité : non-prévisible grâce à la partie aléatoire
- Flexibilité : format structuré mais extensible
Conclusion
Le code présenté ici est spécifique à Go, mais le concept du GID peut être transposé dans n’importe quel langage.
L’objectif principal est de visualiser comment représenter un identifiant global (GID) de manière informative, en regroupant des données métier concrètes (tenant, type d’entité, timestamp) tout en garantissant :
- l’unicité globale,
- et la résistance à la prédictibilité.
Ainsi, le GID permet de créer des identifiants à la fois robustes, traçables et utiles pour le business, tout en restant optimisés pour une architecture distribuée ou multi-tenant.