Everyone can do CRUD - what makes a capstone a story worth telling in an interview is its complex feature. Today that part: where multiple steps, multiple ideas work together. The appearance will change with the option, but the weaving rule is the same.
If it is Khabar Dhandha - the order flow
Placing an order means a long chain: verifying cart items, calculating the price (do not trust the client-sent price - the server calculates it from the menu itself), delivery charge by zone, then order + items + stock together in a transaction. Fix the chain of status changes too - a 'delivered' order can never become 'pending' again. On every status change, notification through the queue, and the customer gets a live update on Socket.io. Three ideas from week 3 meet together here.
// Which path a status can change along - written in one place
const NEXT_STATUS = {
pending: ["confirmed", "cancelled"],
confirmed: ["preparing", "cancelled"],
preparing: ["on-the-way"],
"on-the-way": ["delivered"],
delivered: [],
cancelled: [],
};
if (!NEXT_STATUS[order.status].includes(newStatus)) {
throw new Error("Cannot move from this status to that status");
}If you took another option
If you took the job board, the complex part is filter and search - matching type, place, salary range with a Prisma query, along with cursor pagination, and the application's status flow in the same chain. If you took the chat backend, the complex part is message history pagination and online status - keeping who is online in Redis, so the count matches even when servers grow.
Whichever you do, ask yourself one question at the end of today: can I tell this feature's story in an interview - what the problem was, how I wove which ideas together, why I took which decision? Once the story is ready, the capstone has done its job.
The mistake everyone makes
Breaking the main discipline while building a complex feature - like letting a status change from any state to any state, or accepting an order at the client-sent price. The more complex the feature, the more clearly the rules have to be written in code.
Today's practice
Finish your capstone's complex feature - writing the status chain in code, putting transactions where needed. Then write the feature's story in three or four sentences - that is the interview answer.
How to say it in an interview
Test yourself: 'The hard part of my capstone was keeping a multi-step flow safe - calculating prices on the server, the whole order in a transaction, a fixed chain for status changes, and sending news on every change through queue and real-time.'