Capstone

The capstone follows one change for an online shop: let a customer cancel a paid order within ten minutes, start a refund, and return reserved items to stock. Today customers contact support, wait for an agent, and may miss the warehouse cutoff. The desired user outcome is a clear, trustworthy cancellation without support. The business outcome is fewer avoidable contacts and fewer orders packed after a cancellation request.

Use the product-leadership practice of separating outcomes from output. A cancellation button is output; fewer support contacts and a high rate of eligible self-service cancellations are outcomes. State who is affected, the current problem, the expected behavior, and what is outside scope. For this first release, changing an order or cancelling after packing begins is outside scope. That boundary prevents a useful change from becoming an undefined rewrite of fulfillment.

Turn the outcome into measurable success and safety criteria before discussing storage or queues. Measure the share of eligible requests completed without support, the time until the user sees a final state, and support contacts about cancellation. Guard against duplicate refunds, stock errors, unauthorized cancellation, and increased checkout failures. Record assumptions, such as the warehouse exposing a reliable packing-started state, and assign an owner to verify each one.

Return to the system-foundations method of tracing one request end to end. The browser sends an authenticated HTTPS request to the existing order API. The application checks that the customer owns the order, reads its current state, and records an accepted cancellation. A worker later calls the payment provider for the refund and the inventory component to release stock. The user reads the order API again to see whether cancellation is pending, completed, or needs help.

Draw each component and label each request, response, durable write, and queued message. Mark trust boundaries where authentication and authorization are checked. Mark the transaction boundary around local order changes, and show that calls to the payment provider are outside that database transaction. Add a request identifier to the initial request and carry the order and cancellation identifiers through logs and worker activity so one user action can be traced across asynchronous work.

Walk the map once for success and once for each important interruption. The browser may retry after losing the response, the worker may stop after the payment provider accepted a refund, or the inventory release may fail while the refund succeeds. This review exposes where repeated requests must be safe and where the interface needs an honest pending state. It also identifies system owners who must review the proposal rather than discovering the change during rollout.

Apply the data-storage concepts to facts, not screens. Keep the existing order as the source of truth and add a cancellation record with a stable identifier, order identifier, requester, reason, state, refund reference, timestamps, and failure details safe for operators. A uniqueness rule allows only one active cancellation per order. The decision log should explain why the existing relational database is preferred over a new store: the data is related to orders, requires constraints, and fits known access patterns.

State the invariants and transaction boundary. Only the owning customer or an authorized operator may request cancellation; an order cannot become cancellable after packing starts; and one paid amount can be refunded at most once. In one short transaction, re-read the current order state, create the cancellation record, move the order to cancellation pending, and record work for later processing. Concurrent requests then produce one accepted result rather than two independent refunds.

Choose consistency per operation as taught in Data and Storage. Eligibility and authorization use a current authoritative read because stale state could cancel an already packed order. After acceptance, the customer's next read should show cancellation pending, providing read-your-writes behavior. The refund and stock release may complete later, so the interface names that delay instead of claiming the whole process is complete. Index the customer order-history and worker lookup paths only after writing their real query shapes.

Use performance targets that match the journey. The cancellation request should acknowledge a valid request quickly at the 95th percentile, while the separate completion target measures time from acceptance to final state. Expected volume is modest, so a new cache, service, or shard is not justified. Measure API latency, queue wait, worker time, provider latency, and completion throughput to find a real bottleneck if the target is missed.

Apply the reliability-async practices to the worker path. The queued work contains stable order and cancellation identifiers, not a full mutable order copy. A worker may receive the same work more than once, so it reads durable state and makes each step safe to repeat. Retries use increasing delays for temporary provider failures and stop after a defined limit. Work that still fails remains visible for operator review rather than disappearing or retrying forever.

Set timeouts and failure behavior at each dependency boundary. If the payment provider is slow, the worker times out and retries safely while the order remains pending; it does not tell the user cancellation failed prematurely. If inventory release fails after refund, record that partial state, alert the owning team, and retry only the unfinished step. Limit worker concurrency so recovery traffic cannot overwhelm the provider, and test process loss between every durable update and external call.

Use the technical-excellence practice of making changes small enough to review and reverse. First add the cancellation data model and inactive code paths. Next record and display cancellation state for internal test orders without calling external systems. Then connect the refund step, connect inventory release, and finally expose the customer button behind a server-controlled feature flag. Each slice leaves the system valid and produces evidence for the next decision.

Build the test plan from risks rather than from code structure alone. Unit tests cover eligibility rules and state changes. Database integration tests prove the transaction, uniqueness rule, and concurrent-request behavior. Contract tests cover request and response shapes with the payment and inventory boundaries. End-to-end tests cover acceptance, pending display, completion, authorization, and ineligible orders. Load tests verify the acknowledgement and completion targets at expected peak traffic.

Add focused failure tests for lost responses, duplicate queued work, worker restarts, provider timeouts, exhausted retries, and a partial refund-without-stock-release state. Use provider test environments where possible, but do not mistake them for production behavior. Review test data and log output so payment details and personal data are protected. Assign an owner and pass condition to every test category, and record accepted gaps in the decision log.

A rollout plan connects each exposure step to checks and a decision owner. Begin with team test orders, then a small group of support agents, then one percent of eligible customers, and increase in planned stages. At every stage compare completion, support contacts, and safety measures with the baseline. Leave enough time to observe delayed refunds and stock corrections before increasing traffic.

Create a journey dashboard rather than watching only server health. Show eligible attempts, accepted requests, final outcomes by state, 95th-percentile acknowledgement and completion time, queue age and depth, retry counts, payment and inventory errors, duplicate-refund protection, and support contacts. Alerts should name an actionable condition, such as oldest queued cancellation exceeding the completion target or any confirmed duplicate refund, and route to the owner with a short response guide.

Rollback is more than redeploying old code. The first action is a tested server-side switch that hides the button and rejects new customer requests while workers safely finish or pause accepted work. Keep backward-compatible schema and reads during the rollout, and do not remove records needed to recover pending cancellations. Define who can stop the rollout, exact triggers, how pending work is inspected, how users and support are informed, and what evidence permits resuming.

The final request for comments, or RFC, tells one connected story: the current customer problem, measurable outcome, constraints, chosen design, alternatives, delivery, and operation. Keep the end-to-end diagram near the design text and link each major choice to the decision log. Use terms already established in earlier modules, such as transaction, consistency, percentile, queue, retry, feature flag, and rollback, and briefly restate the relevant consequence instead of adding unexplained vocabulary.

Make review efficient by separating facts, assumptions, decisions, and open questions. For each decision, record the options considered, evidence, tradeoff, owner, and date. Ask reviewers by role: product confirms outcome and eligibility, support confirms user and operator flows, security checks access and sensitive data, payment and inventory owners check boundaries, and operations checks dashboards, alerts, and rollback. Resolve blocking comments in the document so the history remains useful.

Present the RFC as a decision, not a tour of every paragraph. Open with the user problem and success measure, walk the request and data-flow diagram, explain the two or three highest-risk choices, then show delivery stages, safety signals, and rollback. End with the decision needed, remaining owners, and next checkpoint. Presentation notes should include likely questions, concise answers, and places where new evidence would change the recommendation.