Applications & software architecture

A successful stock read is not a reservation. Expiry and payment confirmation need an agreed winner, not two independent booleans.

Both checkouts can read stock=1, both charge, and both decrement, producing oversell or a charged customer with no item. Inventory must atomically reserve against available stock, using a conditional update or transaction that enforces available≥requested. Give each reservation a stable ID and states such as held, confirmed, released. Only one transition out of held can win; checking a timestamp without a conditional state transition is insufficient.

Payment requests need stable idempotency identities and a recoverable pending state. If expiry releases the reservation before a delayed successful payment is reconciled, the system must attempt a new reservation or refund according to an explicit policy. It cannot claim both guaranteed shipment and unconditional release without a coordinating protocol. A local transaction can atomically change inventory and its event/outbox record; it does not atomically commit a remote card processor. Define reconciliation jobs, timeout behavior, audit records, and customer-visible pending states. Test simultaneous reserve, duplicate confirm, confirm-versus-expire, and lost payment acknowledgment. The design is judged by preserved stock and money invariants, not by the number of services.

Check your reasoning

• Give the concrete oversell interleaving.
• Make reserve and terminal transitions atomic.
• Resolve delayed payment after expiry explicitly.

Compatibility is defined by actual old-client behavior and old-server acceptance. Successful transport does not identify the semantic effect.

An old client may use an exhaustive switch with no unknown-status behavior, so a new response enum value can crash or misrender it. Requiring reason rejects old requests that omitted it. Stage the request change by first accepting both shapes, defining a default or maintaining the old path, measuring adoption, and only enforcing the new contract in a negotiated version or after an explicit deprecation process. For response expansion, either preserve the old representation for old clients or first ship clients that tolerate documented unknown values. Test captured old-client contracts against the new server and new clients against the rollback server.

Rollback must account for data already written in the new format; reverting code does not erase cancelled records. Define whether old versions can read them and how any migration is reversed or made forward-compatible. HTTP 200 reports success according to the endpoint contract. It does not make a repeated charge harmless. Retry safety requires idempotent semantics or a durable operation identity, payload consistency checks, and a retention policy.

Check your reasoning

• Test both directions of version compatibility.
• Include persisted data in rollback.
• Separate response codes from effect deduplication.

The empty list is sorted. Compare multisets, not sets, and distinguish a copy contract from in-place sorting.

Returning [] passes the ordering property for every input. Add multiset preservation, including duplicate counts, and assert that the original input is unchanged and the returned object satisfies the promised aliasing contract. For stable key sorting, attach original indices and assert that equal-key output records retain increasing original index. Also test empty input, one element, repeated keys, reverse order, and values at comparator boundaries. A deliberately broken implementation that drops duplicates should fail multiset preservation; one that sorts in place should fail the input-preservation assertion.

Shrink a failure by removing chunks and simplifying values while retaining the failing property; for stability, preserve at least two equal-key distinguishable records. Store the random seed and minimized counterexample. Reproducing the build needs the source revision, lockfile and package-manager version, runtime/toolchain versions, build commands, relevant non-secret configuration, and platform constraints. A lockfile alone does not pin system libraries, generated inputs, timestamps, network downloads, or nondeterministic steps. Use a clean environment and compare outputs or behavior rather than assuming a successful build proves reproducibility.

Check your reasoning

• Use multiplicities, not just set equality.
• Test the documented mutation and stability contracts.
• Preserve a minimal failing case and enough build inputs to reproduce it.

The budget fraction is 0.001 of eligible requests. Burn rate compares observed failure proportion with the allowed proportion.

Allowed failures are 2,000; remaining budget is 500; consumption is 1,500/2,000=75%. The incident has 200 failures and a burn rate of 0.02/0.001=20. If its traffic volume is representative, that rate spends budget much faster than the long-run allowance, but extrapolation must consider traffic changes and rolling-window replacement.

A time-based 99.9% objective over 30 days permits 0.001×30×24×60=43.2 minutes of bad time. That is a different denominator: a short outage at peak traffic can consume far more request budget than a long low-traffic outage. Define eligible requests and failure classifications so client mistakes do not silently distort server reliability. Use multiple alert windows to distinguish a rapid serious incident from noise, and include low-volume handling. With only 25% of the current budget left, a risky release may warrant postponement or a small monitored rollout, but the decision also depends on urgency, rollback ability, and whether the change repairs the active failure.

Check your reasoning

• Compute budget and burn rate using request counts.
• Do not substitute time availability for request success.
• Tie action to measured risk and rollback, not a threshold alone.

Associate every state update with a generation or request identity, not only successful results.

B first displays caterpillar results; A later overwrites them with cat results while the input still says caterpillar. Increment a request generation whenever the query changes. Capture it for each request and apply success, failure, and loading-finalization updates only if it still equals the active generation. Aborting A can reduce work, but the identity check remains necessary because completion can race cancellation and remote work may continue. On unmount, invalidate the generation or suppress updates through cleanup.

The state should distinguish idle, loading for the current query, success, and error, and define whether previous results remain visible during loading. Do not let A's finally block clear B's loading indicator. Announce meaningful status changes through an appropriate live region without moving focus on every keystroke. Keep the input keyboard-operable and preserve focus. Test reversed completion order, A failing after B succeeds, rapid repeated identical queries, empty input, and component teardown.

Check your reasoning

• Guard success, failure, and cleanup updates.
• Treat cancellation as an optimization, not the correctness proof.
• Preserve focus and provide restrained status feedback.