Capstone project for Distributed Systems

Make partner-shop ordering safe across services

Mangrove Market's Partner app lets about 1,800 corner shops order stock wholesale. Today one NestJS API saves the order, then calls the inventory service to reserve stock at the distribution centre, then charges the shop's mobile wallet, then sends an SMS, all inside one request with no timeouts. Last festival week, the wallet provider slowed to 12 seconds, checkout hung, some orders were saved but never reserved, and two shops were charged twice after retries. Ravi, one of the shop owners, now refuses to pay by wallet. Ken, the engineering manager, asks you for a short design and a working proof of the riskiest parts: what each step promises, how events are sent without loss, how failures are undone, how every outside call is protected, and what the shop owner sees while an order is still being confirmed.

What you hand in

A 2 to 3 page design document with a consistency table: one row per feature, what it needs, where it reads from, and what happens when the primary is unreachable
A saga diagram for placing an order, with every step, its event, its compensation, and which steps cannot be undone
The outbox table, the relay's claim query and an idempotent stock consumer, with a test that delivers the same event twice
A dependency table for the wallet, SMS and inventory calls: timeout, retry rule, backoff, breaker settings and fallback
A one-paragraph decision on whether inventory should stay a module or become a separate service, with the specific reason

Check your work

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

Stock reservation is decided in one place with a conditional update, never from a replica or cache
The order and its first event are written in one transaction through an outbox, and the relay uses SKIP LOCKED or CDC
Every consumer and compensation is idempotent, keyed on an event id, and stock can never go negative
Irreversible steps, such as dispatch and the SMS, come after payment is confirmed
A wallet timeout is treated as 'I don't know': the saga checks the payment status or retries with the same idempotency key
Each outside call has a timeout based on its p99, retries at one layer only with full jitter, and its own breaker
The shop owner sees an honest 'confirming' state, a time limit, and a clear message when the order is cancelled
The service-boundary decision names a specific reason or concludes that there is none

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…