BE10: Capstone: three backend projects for TiffinBox

Why each option is right or wrong

• “Start with Project 3, since the projects don't depend on each other” (Incorrect): Project 2's menu change route depends on Project 1's sign-in checks, and the order code changes in Project 1.
• “Do all three at once to finish sooner and keep the work varied” (Incorrect): Working on dependent parts at once leads to rework.
• “Skip the plan and fix whichever test fails first in the output” (Incorrect): Without a plan, it's hard to see progress or estimate time.
• “Do Project 1 first, then 2, then 3, after running every test once” is correct.

  Project 1 fixes sign-in and the order code that the others build on. Running the tests first shows where you stand.

  • Plan: a "done when" check for each week.
  • Save: test output as each project passes.

📖 Revise: Lesson 1: Planning the capstone

Why each option is right or wrong

• “The kit's tests are broken and should be rewritten from the start” (Incorrect): The tests do their job; they can't know about routes you added.
• “Order IDs should be random so this kind of request can't be guessed” (Incorrect): IDs leak; ownership must still be checked.
• “Nothing, because passing 13 of 13 means the API is secure overall” (Incorrect): Passing tests shows those cases work, not every case.
• “The kit's tests cover the routes they name; your routes need their own tests” is correct.

  Tests check what they test. New routes need the same ownership rule and a test of your own.

  • Fix: WHERE id = $1 AND customer_id = $2, 404 for others.
  • Self-review: note it honestly.

📖 Revise: Lesson 2: Project 1: a secure orders API

Why each option is right or wrong

• “The test sends too many requests for a real system to handle” (Incorrect): Parallel repeats happen in real systems (double taps, retries).
• “The key should be stored in server memory instead of the database” (Incorrect): Memory isn't shared between copies and is lost on restart.
• “The client should wait a second between repeats of the request” (Incorrect): You can't control client timing; the server must be safe.
• “Two requests can both see "no key" before either inserts it” is correct.

  Check-then-insert is a race. A unique constraint with ON CONFLICT lets only one insert win; the others read the first result.

  • See: BE1 Lesson 4, BE2 Lesson 3.
  • Test: 5 at once, one order.

📖 Revise: Lesson 2: Project 1: a secure orders API

Why each option is right or wrong

• “Shorten the time-to-live to 5 seconds so old prices fade faster” (Incorrect): Even 5 seconds of old prices fails the test and still shows wrong prices.
• “Turn off the cache for menus, since prices change sometimes” (Incorrect): That gives up the speed; the fix is simple.
• “Ask staff to wait 5 minutes before telling customers about changes” (Incorrect): Customers see the old price in the meantime.
• “Delete the cached menu right after the price update commits” is correct.

  Clearing on change makes the next request load fresh data. The time-to-live stays as a safety net.

  • Kit: cache test 7.
  • Order: update the database, then delete the key.

📖 Revise: Lesson 3: Project 2: a fast, fresh menu

Why each option is right or wrong

• “Remove the rate limiter from the code permanently” (Incorrect): The limit protects the API; only the practice load test needs it raised.
• “Report the numbers anyway, since 429 responses are fast” (Incorrect): Refusals aren't menu responses; the numbers would mislead.
• “Run the test from several machines so each one stays under the limit” (Incorrect): That works around the limit but adds noise; raising it for the test is simpler.
• “Start the API with a high RATE_LIMIT for the load test” is correct.

  The rate limit is refusing most requests, so the numbers measure refusals, not the menu. A high limit for the practice test fixes it.

  • Kit: RATE_LIMIT=1000000 npm run api.
  • Production: keep real limits.

📖 Revise: Lesson 3: Project 2: a fast, fresh menu

Why each option is right or wrong

• “Acknowledge each message before starting the work on it” (Incorrect): That loses messages when the consumer is killed.
• “Add a short sleep between the two inserts to let them settle” (Incorrect): A sleep makes the gap bigger, not safer.
• “Run only one kitchen consumer so there's nobody to double the work” (Incorrect): Repeats also come from crashes and the relay, even with one consumer.
• “Put the dedupe insert and the ticket insert in one transaction” is correct.

  Both commit or neither does, so a crash can't leave one without the other. Then acknowledge after the commit.

  • See: BE7 Lesson 3.
  • Test: test 6, three runs in a row.

📖 Revise: Lesson 4: Project 3: kitchen tickets through a queue

Why each option is right or wrong

• “Redis is too slow for consumer groups with more than one consumer” (Incorrect): Redis handles this easily; the setting is the problem.
• “Claiming is a bad idea and should be removed from the service” (Incorrect): Without claiming, messages from crashed consumers are stuck.
• “The test is flaky and can safely be ignored in the self-review” (Incorrect): It's showing a real problem in the setting.
• “100 ms is shorter than normal work, so live work is claimed too” is correct.

  The idle time should be longer than work usually takes. Dedupe keeps the result correct, but the double work is wasted.

  • Kit: 1000 ms.
  • Check: logs show which consumer handled each message.

📖 Revise: Lesson 4: Project 3: kitchen tickets through a queue

Why each option is right or wrong

• “Redis must be kept running, so the demo condition is unfair” (Incorrect): Redis can fail in real life; the system should cope.
• “The kitchen service should have taken orders directly instead” (Incorrect): That couples the services; the orders service should keep working on its own.
• “Orders should be stored in Redis so they don't need the database” (Incorrect): The database is the source of truth; Redis is the delivery route.
• “The orders service publishes directly instead of using the outbox” is correct.

  With an outbox, orders are saved with their events and accepted while Redis is down; the relay sends events later.

  • Kit: queue test 5.
  • Show: outbox_pending on /health.

📖 Revise: Lesson 4: Project 3: kitchen tickets through a queue

Why each option is right or wrong

• “"Met", since Node.js programs run the same on every system” (Incorrect): Paths, commands and services can differ; you haven't checked.
• “Leave the row out so the self-review looks more complete” (Incorrect): Hiding gaps makes the review less useful and less honest.
• “"Partly", because Linux is similar to Windows in most ways” (Incorrect): "Partly" suggests some checking on Windows, which didn't happen.
• “"Not verified", with a note that you ran it only on Linux” is correct.

  Saying what you didn't check is honest and helps the next developer. Add a plan if it matters.

  • Same rule: for Docker, if you didn't use it.

📖 Revise: Lesson 5: Demo, self-review and case studies

Why each option is right or wrong

• “A comparison with a large company's production numbers” (Incorrect): Comparing with numbers you can't check adds nothing reliable.
• “A screenshot of a cloud bill to show the cost saving” (Incorrect): The practice kit has no cloud bill; invented costs would mislead.
• “Nothing, because a round number is easy for readers to remember” (Incorrect): Easy to remember isn't the same as accurate and labelled.
• “That it's a practice-kit figure, and the machine and test settings” is correct.

  Numbers depend on hardware, data and settings. Labelling them as practice-kit results keeps the claim honest.

  • Include: before and after, with the command used.
  • Add: one honest limit, such as "cached requests only".

📖 Revise: Lesson 5: Demo, self-review and case studies