The ID Space and the Sequencer's Lifetime

In one line: this is the counting argument that Lesson 1 promised, and it produces a number so large it changes what you should worry about.

The constraints

• The generated short URL must contain only alphanumeric characters.
• None of the characters should be visually ambiguous.
• The minimum default length of the generated short URL should be six characters.

How many characters does a 64-bit ID need?

• The number of bits to represent one digit in base-n is log₂n.
• Number of digits = total bits available / bits per digit

Base 10:  log2(10) = 3.32   ->  64 / 3.32 = 19.27  ->  ~20 digits
Base 58:  log2(58) = 5.86   ->  64 / 5.86 = 10.93  ->  ~11 characters

Both figures verify — and 11 characters is the honest maximum

The derivation is correct. A 64-bit value tops out at 18,446,744,073,709,551,615 — twenty decimal digits — and in base 58 that is eleven characters.

Sanity check from the other direction:

58^10 =    430,804,206,899,405,824    <- less than 2^64
58^11 = 24,986,644,000,165,537,792    <- more than 2^64

So eleven characters is exactly enough and ten is not. The maximum short URL is 11 characters, which is short enough to read aloud and type — the readability requirement is satisfied at the top of the range.

Worth noting the general formula, since it recurs: digits = bits / log₂(base). It answers "how long is the string?" for any encoding, and it is the same calculation that told you base 58 and base 64 both need 11 characters in Lesson 7.

Why the range starts at a billion

To ensure short URLs have a minimum length of six characters, we will only use IDs with at least 10 digits (i.e. starting from 1 billion).

The floor is right, and the reasoning is slightly off

Check whether 1 billion actually produces six characters:

58^5 =   656,356,768    <- smallest 6-character value
58^6 = 38,068,692,544   <- smallest 7-character value

1,000,000,000 is between them, so it encodes to 6 characters.  Correct.

So the conclusion holds. But the stated reason — "IDs with at least 10 decimal digits" — is a base-10 criterion for a base-58 property, and the two do not line up exactly.

The precise floor is 58⁵ = 656,356,768, which is a 9-digit decimal number. So the design is discarding IDs between 656,356,768 and 1,000,000,000 that would have encoded to six characters perfectly well — about 344 million of them.

Immaterial, given Lesson 9's lifetime figure. But the habit matters: when a constraint is expressed in one base, derive the bound in that base. "At least 10 decimal digits" happens to be sufficient here; it is not the actual boundary.

The design's own follow-up question notices the waste: "Our system currently uses 10-digit and beyond sequencer IDs. What if we wanted to make them shorter? How could we use the sequencer ID range below 10 digits more effectively?"

The answer: IDs below 58⁵ produce 5-character or shorter URLs — an extremely valuable, tiny space of about 656 million. Those should be reserved deliberately, not spent by the sequencer at random. They are the natural home for premium custom aliases, which is a product decision the design leaves open.

The sequencer's lifetime

Available IDs   = 2^64 - 10^9 = 18,446,744,072,709,551,616
Requests/year   = 200M x 12   = 2.4 billion

Lifetime = 18,446,744,072,709,551,616 / 2,400,000,000
         = 7,686,143,363.63 years

Seven point seven billion years — and what that number actually tells you

The arithmetic verifies exactly, to two decimal places.

For calibration: the Sun will render Earth uninhabitable in roughly 1 billion years and become a red giant in about 5 billion. The sequencer outlives the planet by a factor of seven.

That is obviously absurd as a planning horizon, and the useful reading is not "we have enough IDs." It is:

The ID space is not a constraint, so stop designing around it. No reclamation of expired IDs, no compaction, no ID-recycling scheme. Lesson 2 noted the design deliberately does not reuse expired IDs, and this is the justification — reuse would buy nothing and cost a security property.

64 bits is enormously oversized for this problem. You could use 48 bits and still have:

2^48 / 2.4 billion = 117,000 years

Which is still absurd, and would cap short URLs at 9 characters instead of 11 — shorter, more readable, and still collision-free for longer than civilization has existed.

When your capacity calculation returns a number larger than the age of the universe, the parameter is over-provisioned and you should ask what a smaller one would buy you. Here it would buy two characters off every URL, which is a real improvement to the readability requirement.

That is the most useful thing in this lesson: the lifetime figure is not reassurance, it is evidence that 64 bits is the wrong size.

The gap between minimum and typical length

Two numbers now sit in tension, and Lesson 10 develops the consequence.

Minimum length: 6 characters — from the 1-billion floor. Maximum length: 11 characters — from the 64-bit ceiling.

So which do users actually get? It depends on how the sequencer picks, and Lesson 6 established that it selects randomly from its assigned range to satisfy unpredictability.

A random value from a range spanning 10⁹ to 2⁶⁴ is overwhelmingly likely to be near the top, because each additional character multiplies the space by 58:

Values needing 11 chars: 97.7% of the range
Values needing 10 chars:  2.3%
Values needing <=9 chars: 0.04%

So the typical short URL is 11 characters, not 6. The "minimum default length of six characters" is true and misleading — it describes a floor almost nothing reaches.

Which means the readability requirement is being satisfied much less well than the design implies, and Lesson 10 shows the reason it cannot simply be fixed by using shorter IDs.

Next: the conflict between the requirements.