Skip to content
Case study 1

A URL shortener

People paste a long link and get back a short one like ar.dr/x7Kq2. Every click on the short link asks the service where it points, then redirects.

Creating links is rare; following them is not. Nine requests in ten are redirects, and a few links (the ones in a viral post) get most of the clicks: the traffic is skewed.

You start with two app servers in front of one database. At 6,000 requests a second they are swamped. Make it fast and reliable without spending more than you need to.

Requirements

  • Create a short link for a long URL (a write).
  • Redirect a short link to its URL (a read): 90% of traffic.
  • 6,000 requests a second, with a few popular links taking most of the clicks.
  • Redirects must feel instant, and the service must not drop requests.

Traffic

6K requests a second, 90% reads

20K distinct keys, a few of them very hot

Targets

  • At least 5.9K successful requests a second
  • p99 latency at most 50 ms
  • At most 1% of requests fail, time out or are rejected
  • Costs at most $800 a month
Next case: An API that survives a spike

Components

  • Clients, Clients: 6K req/s, 90% reads
  • Load balancer, Load balancer: round robin
  • App servers, App servers: 2 × app, 8 workers
  • Database, Database: primary only

Connections

  • Clients to Load balancer: requests
  • Load balancer to App servers: spread
  • App servers to Database: reads & writes

Select a component in the diagram to change its settings and connections, or add one above.

Check the design

Runs 10 simulated seconds of the case’s traffic, and checks every target.

Showing a solution replaces your design on screen until you switch back.