Design a URL shortener and defend its key-generation and storage trade-offs

Read the full interview experience this question came from →

Quick Overview

Design a URL-shortening service that creates short links and redirects visitors to the original address. The discussion centers on defending trade-offs: how short codes are generated and kept unique, how storage and caching serve a read-heavy redirect path, and how analytics, expiration, abuse and failures are handled.

Design a URL shortener and defend its key-generation and storage trade-offs

Company: Oracle

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

Design a URL-shortening service. A user submits a long URL and receives a short link; anyone who opens the short link is redirected to the original URL. The report describes the round as a standard version of this problem in which the interviewer pressed hard on trade-offs, so be ready to defend each major choice against its alternatives. ```hint Two very different paths Treat link creation and redirection separately: compare how often each one happens and what each needs in order to be fast and correct. ``` ```hint Where the short code comes from List more than one way to produce a code that is unique, short and hard to guess, and note what each way needs from the rest of the system. ``` ### Clarifying Questions - Roughly how many links are created per day, and how many redirects does a typical link receive? - Do users need custom aliases, link expiration, editing or deletion? - Is click analytics required, and how fresh must it be? - Must a newly created link work immediately in every region? - Should the same long URL always produce the same short link? ### What a Strong Answer Covers - Functional and non-functional requirements, with capacity estimates that drive the code length and storage size - A short-code generation scheme with collision handling, compared with at least one alternative - Data model and API for creation, redirection and the optional features - The redirect path: caching, the choice of redirect status code, and protection against lookups of unknown codes - Scaling, replication and failure handling for both paths, plus abuse prevention and observability ### Follow-up Questions - Why might you choose a 302 redirect over a 301, and what does it cost? - Two servers generate the same code at the same moment. How does your design detect or prevent it? - Codes are sequential, and someone enumerates all your links. How do you stop that? - One link goes viral and receives a large share of all traffic. What happens to your cache and your storage?

Overview: Design a URL-shortening service that creates short links and redirects visitors to the original address. The discussion centers on defending trade-offs: how short codes are generated and kept unique, how storage and caching serve a read-heavy redirect path, and how analytics, expiration, abuse and failures are handled.

Read the full Oracle Software Engineer interview experience this question came from

Oracle logo
Oracle
Oct 29, 2026
mediumSoftware EngineerOnsiteSystem Design
0
0

Design a URL-shortening service. A user submits a long URL and receives a short link; anyone who opens the short link is redirected to the original URL. The report describes the round as a standard version of this problem in which the interviewer pressed hard on trade-offs, so be ready to defend each major choice against its alternatives.

Clarifying Questions Guidance

  • Roughly how many links are created per day, and how many redirects does a typical link receive?
  • Do users need custom aliases, link expiration, editing or deletion?
  • Is click analytics required, and how fresh must it be?
  • Must a newly created link work immediately in every region?
  • Should the same long URL always produce the same short link?

What a Strong Answer Covers Guidance

  • Functional and non-functional requirements, with capacity estimates that drive the code length and storage size
  • A short-code generation scheme with collision handling, compared with at least one alternative
  • Data model and API for creation, redirection and the optional features
  • The redirect path: caching, the choice of redirect status code, and protection against lookups of unknown codes
  • Scaling, replication and failure handling for both paths, plus abuse prevention and observability

Follow-up Questions Guidance

  • Why might you choose a 302 redirect over a 301, and what does it cost?
  • Two servers generate the same code at the same moment. How does your design detect or prevent it?
  • Codes are sequential, and someone enumerates all your links. How do you stop that?
  • One link goes viral and receives a large share of all traffic. What happens to your cache and your storage?