1. Courses
  2. Scaling Building Blocks
  3. Capstone

Capstone project for Scaling Building Blocks

Get Mangrove ready for festival week

Mangrove Market expects four times its normal app traffic during the coming festival week: about 240,000 orders a day instead of 60,000, most of them between 6 pm and 10 pm. Today the customer app's API runs as one NestJS process on one VM. Product photos are saved on that VM's disk, the order confirmation SMS is sent inside the checkout request, OTP login has no limit, the catalogue is read straight from Postgres on every tap, and customers refresh the order screen to see whether a rider has picked up. Ken, the engineering manager, asks you for a short design document and a small proof of concept that make the system ready: several stateless copies behind a load balancer, a catalogue cache, photos in object storage behind a CDN, SMS through a queue, rate limits on login, and live order status.

What you hand in

  1. A 2 to 3 page design document with one diagram of the target setup and the capacity math for the evening peak
  2. A list of every piece of hidden state in today's API and where each one moves
  3. A cache plan table: what is cached, where, the TTL, how it is invalidated, and what is never cached
  4. Working code for at least two pieces, for example the cache-aside helper with a stampede lock, the idempotent SMS worker, or the token bucket, with a short test for each
  5. A one-page festival runbook: which numbers to watch and the first action when each one goes wrong

Check your work

Tick each item when your project meets it. Be strict: this is the rubric the reviewer uses.

  • The capacity math starts from a peak requests-per-second estimate, uses a stated per-copy capacity with headroom, and adds a spare
  • Every piece of state (sessions, photos, caches, scheduled jobs, counters, sockets) has a named new home
  • The load balancer section names the algorithm, the readiness check, the timeouts, and how the balancer itself avoids being a single point of failure
  • The cache plan gives each item a TTL and an invalidation rule, and keeps stock reservation and payments out of the cache
  • Photos are uploaded with presigned URLs and served with hashed or random names and long cache headers; private files never sit behind a public URL
  • The SMS queue has idempotent workers, capped retries with backoff, and a dead-letter queue that someone watches
  • Rate limits use sensible keys (phone number and IP for OTP, user or store elsewhere) and return 429 with Retry-After
  • Live status uses SSE or WebSockets while the app is open, push only for the moments that matter, and a catch-up after every reconnect

0 of 8 checked

Model answer

The model answer opens once your capstone passes the review, so you can compare your work with an outline of a strong submission.

Hand in your capstone

Your links are checked automatically, then the work is scored against the rubric above, item by item, with comments. A pass counts toward the course certificate and shows on your profile.

Loading…