BE10: Capstone: three backend projects for TiffinBox
Planning the capstone
🎯You'll be able to
Plan the capstone: scope, order of work, evidence and time.
🏠The everyday picture
A builder renovating a restaurant fixes the wiring and locks first, then the kitchen, then the delivery hatch. Doing the hatch first would mean tearing it out again when the wiring changes.
📘What it really is
- The three projects, all in the TiffinBox kit:
- Secure orders API: real token checks, ownership from the token, validation, server pricing, idempotent orders and a shared rate
limit (13 tests in
npm run test:api); - Fast, fresh menu: one query instead of N+1, an index, a Redis cache that's cleared on change and survives Redis being down (9
tests in
npm run test:cache); - Kitchen tickets through a queue: an outbox in the orders service and a consumer group in the kitchen service, with dedupe,
claiming and a dead-letter stream (7 tests in
npm run test:queue). - Build in this order: Project 1 first (Project 2's menu change route needs its sign-in checks), then Project 2, then Project 3.
-
Each project already has acceptance tests in the kit and a marking guide on its project page. Add your own criteria too, such as "no route takes a customer ID from the request".
-
Use this overview to judge your own work (each project page has the detailed marking guide):
| Area | What "good" looks like |
|---|---|
| API design | Clear routes, status codes, problem details, idempotency (BE1) |
| Data | Constraints, transactions and migrations that keep data right (BE2) |
| Fast | Few queries, the right index, sensible pool use, measured (BE3) |
| Cached | Correct, fresh after changes, safe when Redis is down (BE4) |
| Secure | Tokens verified properly, ownership checked, input limited, rate limited (BE5–BE6) |
| Reliable messaging | Outbox, consumer groups, idempotent consumers, dead letters (BE7) |
| Resilient | Timeouts, fallbacks, stateless copies (BE8) |
| Tested and observable | Integration tests, contracts, logs and SLOs (BE9) |
📝A worked example
A learner's capstone plan (illustrative):
| Week | Work | Done when |
|---|---|---|
| 1 | Project 1: token checks, scopes, ownership | Tests 1 to 7 of npm run test:api pass |
| 2 | Project 1: validation, pricing, idempotency, rate limit | All 13 pass three runs in a row |
| 3 | Project 2: menu query, index, cache, invalidation | All 9 of npm run test:cache pass; load test numbers recorded |
| 4 | Project 3: consumer group, dedupe, dead letters, outbox | All 7 of npm run test:queue pass three runs in a row |
| 5 | Capstone checks, demo, self-review and case studies | npm test shows 29 passed in one session; every project page saved as self-checked complete |
Doing Project 1 first meant the menu change route already required menu:write when Project 2 needed it.
🌍Where it's used
- Product teams taking over a backend with known problems.
- Security and performance rescue work on live systems.
- Portfolios for backend job applications.
📝Case scenario
A learner starts with the queue project because it seems most interesting, then finds the orders route they connected to it still trusts client prices. They rework the order code for Project 1 and have to change their outbox payload too. Reordering to API, menu, queue would have avoided the rework.
🖱️Try it
Download the kit, follow tiffinbox/README.md to set up the database, and run npm test once. Note how many tests fail in each file.
Then write your plan with a "done when" check for each week. Success: your plan lists all 29 tests across the three projects.
⚠️Common mistakes
- Starting without running the tests. Sign: no idea how far you are. Fix: run
npm testfirst and record what fails. - Leaving evidence to the end. Sign: no test output for earlier work. Fix: save output as each project passes.
🛠️For your project
Run the kit's tests once before you plan, so you know what fails now: on the starter, 2 of 13 API tests, 2 of 9 cache tests and 1 of 7 queue tests pass.
✅Quick check
Why build Project 1 before Project 2?
Show the answer
Project 2's menu change route depends on Project 1's token and scope checks.
What should you record as you go?
Show the answer
Test output and measurements for each project, saved as each one passes.