Skip to content
All problems

Canary rollout for a checkout coupon-validation API

EasyAbout 30 minutes

Before you start:Load Balancing

Your attempt

A complete grade of 70 or more solves it.

An e-commerce checkout calls a small internal API to validate a coupon code and work out the discount it unlocks, before the order total is shown. It is a simple API by request-response standards — one table lookup, one answer — but it sits directly in the checkout path, and the team ships to it several times a week. A bad release here does not crash the site; it quietly breaks discounts for whoever it reaches. You own how a new release reaches checkout safely.

What the rollout does

  • New code ships as a canary. A small, fixed share of validation calls reach it first, while the rest keep going to the current version.
  • When the canary crashes or stops passing its health checks, it is pulled out of rotation automatically, before anyone has to notice and act on it.
  • Both versions read the same coupon data, so they never disagree about whether a code is still valid.

The numbers

  • About 9.5 million orders check out a day, and the evening peak runs at about twice the daily average. Checkout validates the applied code each time it recomputes the total, about ten times per order.
  • A validation costs about 3 ms of CPU on either version.
  • The canary is fixed at 8% of validation traffic, whatever the total load is.
  • A health check every 5 seconds, with 2 consecutive failures needed, is how a crashed instance is found and pulled from rotation.

Set these on your components: the load balancer's algorithm and canary weight, its health check's interval and failure threshold, and each version's instance count.

What good looks like

A coupon validates within 150 ms at p99, and at most one request in a thousand fails, while both versions are healthy. If the canary crashes outright, at most one request in ten fails across all of checkout — the canary's own share bounds it — and checkout is back under 1% failures a second within 15 seconds.

In the Sandbox, weighted routing sends the canary share to the last target you connect the load balancer to, and the tests' canary drill crashes the first service on the canvas. So place the canary version before the current one, and connect it to the load balancer last.

Where to start

Do the estimation step first: the canary's share is what actually bounds the blast radius of a bad release, and the health check's interval and threshold are what bound how long a crash stays live. Then put two versions behind one load balancer and kill the canary in the Sandbox to see how quickly it is pulled out. Out of scope: the coupon-authoring tool itself, fraud detection on coupon use, comparing the canary's answers and metrics with the current version's, and the rest of the checkout flow.

Requirements

Functional

  • Checkout calls the API to validate a coupon code and get the discount it unlocks, synchronously, before the order total is shown.
  • New code ships as a canary. A small, fixed share of validation calls reach it first; the rest keep going to the current version.
  • When the canary crashes or stops passing its health checks, it is pulled out of rotation automatically, before anyone has to act on it.

Non-functional

  • Both versions sit behind one load balancer. Health checks decide who is in rotation.
  • Coupon data lives in one managed, already-redundant table shared by both versions.
  • Canary traffic never exceeds a small, fixed share of the whole, whatever the total load is.

Estimation

Before you draw, estimate these. The workspace checks each answer against its band as you type.

  1. Validation calls per second at the evening peak (requests/s)
  2. Share of checkout a bad canary can affect, before it is pulled (ratio)
  3. Longest a bad canary stays in rotation once it starts failing (s)

Tests

2 sample tests you can read and run

  • Coupons validate fast at the checkout peak (Performance)
  • The canary never carries more than its fixed share (Functionality)

1 hidden test, graded when you submit

  • Reliability1

What the design must meet

Service levels

  • A coupon validates within 150 ms at p99, measured at checkout.
  • With both versions healthy, at most one request in a thousand fails.
  • While a bad canary is live, at most one request in ten fails across all of checkout.
  • Within 15 seconds of the canary crashing, requests fail at under 1% a second again.

Load

  • The evening checkout peak runs at about twice the daily average, and checkout validates the applied code about ten times per order.
  • The canary never carries more than 8% of validation traffic, whatever the total load is.

How an attempt runs

  1. RequirementsWhat the service must do, and the numbers it must meet
  2. EstimateSize the load before you draw
  3. DesignBuild it on the canvas and run traffic through it
  4. TestRun the sample tests in your browser
  5. SubmitThe hidden tests grade the design