## Design a Cash Register with Inventory and Profit Tracking Design an object-oriented cash-register system that manages inventory, completes sales, and reports realized gross profit in real time. For a concrete baseline, products have stable IDs and sale prices. Stock arrives in batches with a quantity and acquisition cost per unit. A checkout contains one or more product IDs and quantities. Use FIFO cost allocation: sold units consume the oldest available stock first. Realized gross profit is sales revenue minus the acquisition cost of the units actually sold. ### Constraints & Assumptions - Represent money in integer minor units or an exact decimal type, never binary floating point. - Reject a checkout atomically if any requested quantity is unavailable. - A retry of the same checkout request must not sell or count the inventory twice. - Product price changes affect future sales, not already committed sale records. - Do not assume a particular inventory size, checkout rate, or persistence technology. ### Part 1 — Model Products, Stock, and Sales Define the core classes, invariants, and public methods for registering products, receiving stock, checking availability, and viewing a completed sale. #### What This Part Should Cover - Stable product identity separated from mutable display and price data. - FIFO stock lots retaining quantity and acquisition cost. - Positive-quantity and exact-money validation. - An immutable sale record with line-level revenue and cost. ```hint Keep cost history with the stock Current quantity alone cannot reconstruct profit when replenishment batches have different acquisition costs. ``` ### Part 2 — Commit a Checkout Correctly Describe the checkout flow when several products are purchased together. Address insufficient stock, two registers selling the last unit concurrently, and a client retry after an ambiguous timeout. #### What This Part Should Cover - Validation before any externally visible partial mutation. - One transaction or equivalent critical section for inventory and sale creation. - Deterministic lock ordering or another strategy that avoids overselling and deadlock. - An idempotency key bound to the original request and response. ```hint Define one commit boundary Inventory decrements, FIFO cost allocation, and the durable sale record must agree on whether the checkout happened. ``` ### Part 3 — Report Profit and Test the Design Explain how current realized profit is calculated and reconciled. Give tests for batch costs, partial lot consumption, concurrent sales, failed checkouts, and retries. #### What This Part Should Cover - Profit derived from committed sale-line revenue and cost of goods sold. - A fast running projection with an authoritative recomputation path. - Audit records that explain every stock and profit change. - Complexity in checkout-line count and stock lots consumed. ```hint Preserve the ledger behind the total A single mutable profit counter is fast to read but cannot explain or repair a mismatch by itself. ``` ### What a Strong Answer Covers - Connects the object model to atomic checkout behavior rather than presenting isolated classes. - Uses an explicit FIFO policy to make profit deterministic. - Prevents overselling and double-counting under concurrency and retries. - Keeps immutable evidence from which inventory and profit projections can be checked. ### Follow-up Questions 1. How would returns restore inventory and reverse profit under FIFO accounting? 2. What changes if sale prices can be overridden at checkout with manager approval? 3. How would multiple physical registers share inventory without one process-wide lock? 4. How could inventory snapshots speed recovery while retaining an auditable event history?