Skip to content

Design a URL Shortener, stage 9 of 9: defend it

Defend the simple design

Your interviewer pushes back: "This wouldn't scale. I'd expect Cassandra for the links, Kafka for clicks, a dedicated ID-generation service, and separate microservices for creation, redirect and analytics. Why didn't you do that?"

System so far· 8 parts
12345678CLIENTClickersEDGECDN edgeSERVICERedirect serviceDATABASEPostgresSERVICELinks APICLIENTCustomerdashboardLOG / STREAMClick streamWORKERClick aggregator

Select a component to see what it is responsible for and which state it owns.

  1. 1Clickers → CDN edge: GET /aZ3kQ9x
  2. 2CDN edge → Redirect service: Cache miss
  3. 3Redirect service → Postgres: Look up code
  4. 4Customer dashboard → Links API: Create, edit, disable
  5. 5Links API → Postgres: Insert with unique code
  6. 6Redirect service → Click stream: Click event (fire and forget)
  7. 7Click aggregator → Click stream: Read click batches
  8. 8Click aggregator → Postgres: Upsert daily aggregates
  • Request / response
  • Asynchronous

What you need to know

0 of 1 checks done
  1. "Would this scale?" is a question about numbers, so answer with numbers. For each component the interviewer suggests, say two things:

    1. What it would buy you. Every one of those components solves a real problem.
    2. The trigger. Which measurement would tell you it's time to add it.

    That shows you know what each component is for, without adding them all up front.

  2. Check

    Which is a good trigger for moving the links from Postgres to a partitioned store like Cassandra?