Why Is Redis INCR a Bad Fit for a Public URL Shortener?

LeetDezine — Thu, 23 Apr 2026 17:18:06 +0000

Redis INCR is one of those solutions that looks perfect the first time you see it. Atomic counter increments. Every call returns a unique integer. Base62-encode it and you have a short code — zero collision checks, zero retries, no background service.

It's cleaner than anything else on the board. So why does every serious URL shortener reject it?

The answer has nothing to do with code generation.

How Redis INCR Works (And Why It's Technically Correct)

The mechanics are clean:

Creation request arrives
→ Redis: INCR url_counter → returns 1000000
→ Base62 encode 1000000:

  Divide repeatedly, collect remainders, stop when quotient = 0:

  1000000 ÷ 62 = 16129  remainder 22 → 'M'  (quotient != 0, keep going)
  16129   ÷ 62 = 260    remainder 9  → '9'  (quotient != 0, keep going)
  260     ÷ 62 = 4      remainder 12 → 'C'  (quotient != 0, keep going)
  4       ÷ 62 = 0      remainder 4  → '4'  (quotient = 0, stop)

  Read remainders bottom to top: "4C9M" → pad to 6 chars → "004C9M"

→ INSERT short_code = "004C9M"
→ Done.

Redis is single-threaded. INCR is atomic — it increments and returns in a single operation. Two simultaneous calls always get different values:

App server 1: INCR → 1000000
App server 2: INCR → 1000001  ← different, guaranteed
App server 3: INCR → 1000002  ← different, guaranteed

No race condition. No collision. No retry loop. Encoding a unique number always produces a unique code. The math is correct.

So what's the problem?

Problem 1 — Sequential Codes Are a Privacy Violation

Counter values are sequential. If your user receives yoursite.com/004C9M, they immediately know:

yoursite.com/004C9L  ← previous URL, someone else's
yoursite.com/004C9N  ← next URL, someone else's
yoursite.com/004C9K  ← keep going...
yoursite.com/004C9J  ← and going...

They can walk the entire database. Every URL in your system is discoverable by incrementing one character.

For an internal tool where all users are trusted, this might be fine. For a public shortener — where someone might shorten a pre-announcement link, an internal doc, a private file, a personal photo album — it's a real privacy violation. Your users have a reasonable expectation that their short link isn't guessable.

Sequential codes make that expectation impossible to satisfy.

Problem 2 — Redis Becomes a Hard Dependency on Every Creation

With INCR, the hot path looks like this:

Request → INCR Redis → encode → INSERT DB

Redis is in the critical path of every single URL creation. If Redis goes down:

Redis down
→ INCR fails
→ No counter value
→ Creation fails immediately
→ Zero fallback

There's no graceful degradation. No buffer. No local state to drain. The moment Redis is unreachable, your creation endpoint returns errors.

The Fix: KGS + Pre-Generated Key Pool

The Key Generation Service approach flips the model. Instead of generating a key at request time, keys are generated in advance and stored in a Redis pool. When a request arrives, the app server just pops one.

Before any request arrives:
→ KGS generates random base62 codes offline
→ Loads them into Redis list (RPUSH)

When creation request arrives:
→ App server pops key from local batch
→ INSERT into DB
→ Done — zero Redis call on hot path

Why LPOP is atomic: Redis is single-threaded. Even if 20 app servers call LPOP at the same millisecond, Redis processes them one at a time:

App server 1: LPOP → "x7k2p9" (removed)
App server 2: LPOP → "k2m8q1" (removed)
App server 3: LPOP → "p9n3r7" (removed)

Physically impossible for two LPOP calls to return the same key. No locks needed. No SELECT FOR UPDATE. Atomicity comes from the architecture.

The batch pre-fetch: Each app server grabs 100 keys at startup and keeps them in local memory. At 1k creations/sec across 20 servers, Redis traffic drops from 1000 LPOP/sec to ~10 batch refills/sec. 100x reduction.

App server starts:
→ LPOP 100 keys → store in local queue

Creation request:
→ Pop from local queue (zero network call)
→ Queue empty → refill from Redis

What this fixes for Redis failure:

Redis down
→ App servers drain local batch (100 keys × 20 servers = 2000 keys)
→ At 1k creations/sec → ~2 seconds of local runway
→ Circuit breaker engages, Redis recovers
→ Graceful degradation instead of hard failure

Side by Side

	Redis INCR	KGS + Pool
Collision checks	None	None
Code predictability	Sequential — enumerable	Random — private
Redis failure	Creation fails instantly	Local batch buys time
Operational cost	Very simple	Small background worker
Right for	Internal tools	Public URL shortener

The Pattern

Redis INCR fails not because of what it does, but because of what it leaks. Sequential uniqueness and privacy are in direct conflict. You can't have both with a counter.

The KGS + pool approach keeps the "no collision checks, no retries" guarantee while adding randomness and resilience. The operational cost is a 50-line background worker and one metric to monitor. The privacy and fault tolerance gains are worth it for any public-facing system.

The full URL shortener case study — including requirements, DB design, caching, peak traffic, and every failure mode — is at:

→ https://leetdezine.com/?utm_source=devto

Why Random UUIDs are Killing Your Database Performance

LeetDezine — Mon, 20 Apr 2026 10:15:57 +0000

Every developer starts with a UUID. It’s the industry standard for a reason: zero coordination, zero DB checks, and zero single point of failure. Any machine can generate one and be 100% sure it’s unique.

But as your system scales, that "standard" choice starts to hurt.

The Problem: UUIDs vs. Databases

If you're using UUID v4 (completely random), you're essentially handing your database a grenade.

Because the IDs are random, every new insert lands in a random spot in your B-Tree index. This causes page splits, fragments your storage, and slows down your writes as the table grows. Plus, at 128 bits (16 bytes), they're twice as large as a standard BIGINT.

The Evolution of ID Generation

Single Server Counter: Simple, but if the server dies, your ID generation stops (SPOF).
UUID v4: Globally unique, but random and huge. No time-sortability.
UUID v7: The modern middle ground. It's still 16 bytes, but it's time-sortable, which fixes the database page-split problem.
Ticket Server (Redis): Centralized counter. Fast, but now your ID generation depends on Redis availability.
Snowflake IDs: The "Big Tech" solution (used by Twitter, Discord, and Instagram).

Why Snowflake Wins

Snowflake IDs pack everything you need into just 64 bits (8 bytes). They fit perfectly into a standard BIGINT, making them fast to index and easy to store.

Here is the breakdown of how those 64 bits are structured:

1 bit (Sign): Always 0 (keeps the number positive).
41 bits (Timestamp): Milliseconds since a custom epoch. This gives you ~69 years of IDs and makes them natively time-sortable.
10 bits (Machine ID): Allows up to 1,024 independent nodes to generate IDs simultaneously without talking to each other.
12 bits (Sequence): A counter for IDs generated in the same millisecond on the same machine (up to 4,096 IDs/ms).

The Comparison

Property	UUID v4	UUID v7	Snowflake
Size	128-bit	128-bit	64-bit
Sortable	❌ No	✅ Yes	✅ Yes
Coordination	✅ None	✅ None	✅ None
DB Friendly	❌ No	✅ Yes	✅ Best

Which one should you choose?

Quick Prototypes: Stick with UUID v4. It’s easy and requires zero setup.
Modern Web Apps: Move to UUID v7. You get the simplicity of UUIDs with the performance of time-sortable IDs.
High-Scale Systems: Go with Snowflake. When every byte and every millisecond of database latency matters, 64-bit sortable IDs are the only way to go.

The Golden Rule: You can't just "trim" a UUID to make it shorter. Trimming 128 bits down to 6 characters for a "short link" throws away 92 bits of entropy, turning a global guarantee into a collision nightmare.

For a full deep dive into the math and architecture behind distributed IDs, check out the case study at LeetDezine

Forem: LeetDezine