How we scaled ZipZy short links to 50M redirects a month

Every short link is a promise: tap it, and you land where you expect, instantly. Keeping that promise at scale is harder than it looks. Here's how the ZipZy redirect layer evolved.

The naive first version

Our first redirect handler did exactly one thing: look up a slug in MySQL, then issue a 302. It worked beautifully — until it didn't.

The database is not a cache. Treating it like one is the fastest way to page yourself at 3am.

Adding an edge cache

We moved hot slugs into an in-memory layer and let the edge do the heavy lifting.

Here's the simplified lookup:

async function resolve(slug: string): Promise<string | null> {
  const cached = await edge.get(slug);
  if (cached) return cached;
 
  const row = await db.query("SELECT dest FROM links WHERE slug = ? LIMIT 1", [slug]);
  if (!row) return null;
 
  await edge.set(slug, row.dest, { ttl: 3600 });
  return row.dest;
}

What we measured

The checklist we now follow

• Cache resolutions at the edge
• Set a sane TTL and invalidate on edit
• Keep the DB path fast for the 1% miss
• Move analytics writes fully async (in progress)

Small, boring decisions compound. That's the whole trick.¹