jonnifyelixir
F4 / F4.07 / branded

F4.07 · part 3 of 3

Branded ids

A 64-bit integer is right for a database column, but awkward in a URL, a log line, or a support ticket. A branded id dresses it for the outside: encode the integer in base62 — the alphabet 0-9A-Za-z, url-safe with no punctuation — left-pad it to eleven characters, and prepend a three-letter namespace. The result is PGE0NbWMtkosp8: self-describing, compact, and still sortable.

One Snowflake, 319545566822428714, taken through encode → brand → decode. Every step is computed on this page.

Integer to branded string Advanced: why base62, and why the order survives

Integer to branded string

Branding is reversible: encode the integer to base62, prepend the namespace, and to read it back, strip the three-letter prefix and decode the rest. Select a step to see the value it produces.

Step · select one

snowflake 319545566822428714 ↓ base62 (11) 0NbWMtkosp8 ↓ branded (14) PGE0NbWMtkosp8 base62 turns the 64-bit integer into eleven url-safe characters 

      

      
role: integer to base62

      
result: 0NbWMtkosp8

    

    
A branded id is a lossless skin over an integer: encode and prefix on the way out, strip and
      decode on the way in. The database keeps the 64-bit number; everyone else sees a tidy string.

  


  

    
Advanced: why base62, and why the order survives

    

      
Base64 is more common, but its alphabet includes +, /, and
        = padding — characters that need escaping in URLs and look wrong in an id.
        Base62 drops them, keeping only 0-9A-Za-z, so a branded id is safe
        in a path, a query string, a filename, or a double-click. Eleven base62 characters cover
        62¹¹, which is greater than 2⁶⁴, so
        any Snowflake fits with room to spare; left-padding to a fixed eleven keeps every id the same length.

      
Fixed width is what preserves order. Because every payload is exactly eleven characters, comparing two
        branded ids character by character compares their integers digit by digit — so the lexical order of the
        strings is the numeric order of the Snowflakes, which is time order. Branding changes how an id
        looks, never how it sorts. The namespace prefix sits in front, shared by every id of a
        kind, so it never disturbs that order; it only tells a reader, and a router, what the id points at. This is
        the id the branded CHAMP map of F4.09 keys on, partitioned by that very prefix.

    

    
# EchoData.Base62 — alphabet "0-9A-Za-z", width 11
EchoData.Base62.encode(319545566822428714)
# => "0NbWMtkosp8"

branded = "PGE" <> "0NbWMtkosp8"        # => "PGE0NbWMtkosp8"
EchoData.Base62.decode(String.slice(branded, 3, 11))
# => {:ok, 319545566822428714}

    

      

        
F4.07 · a branded id

        
A namespaced, base62 string over a time-ordered 64-bit integer.

      

      
      

        
F4.08–F4.09 · keys

        
The id becomes a database key, then a key in a branded CHAMP partitioned by namespace.

      

    

    
That completes F4.07: a Snowflake is chosen for order without coordination, packed into 64 bits,
      and branded into a url-safe string. Next module: F4.08 — Branded ids & persistence
      (in production), where the id becomes a key in SQLite, PostgreSQL, and Redis, ahead of the branded CHAMP map of
      F4.09.

  


  

    
References

    
Primary sources for this lesson, and where it connects in the course.

    

      
Sources

      
      
Related in this course