One Purchase, Fully Accounted

A single purchase exercises this entire unit twice — once as a transaction the operational database must guarantee, and again as a fact the analytical stores must remember — with every hand-off named.

A customer buys a jacket. The operational side moves first: the order is a transaction (0424) — inventory decremented, payment recorded, order created as one logical unit — and ACID (0425) holds it together: atomically whole, consistent with the rules, isolated from the thousand simultaneous carts, durable once confirmed, at the processing cost video 0426 priced. The rows land in a relational database (0420) built the way video 0445 practiced: customer stored once, order threaded to it by foreign key (0422), normalization (0427) keeping the address in exactly one place. Then the purchase begins its second life. That night, ETL (0438) extracts the day's orders, transforms formats from every regional system, and loads the warehouse (0437) — the schema-first repository where the jacket becomes a data point in a quarter's apparel trend, feeding the marts (0439) each department reads at morning. Meanwhile the raw exhaust — the clicks before the purchase, the searches, the abandoned cart from Tuesday — pours into the lake (0441) unshaped, at big-data scale (0442), waiting for questions nobody has asked yet, including the learning pipelines this course pointed elsewhere (0443). One jacket, two record-keeping philosophies: the operational store guaranteeing the present tense, the analytical stores interrogating the past — and the unit's claim is that every step between them has a name, a mechanism, and a receipt.