Amazon: order to doorstep, and working backwards

I would split it into owned services behind APIs: cart and checkout, payments, an order service, inventory and promise, fulfilment-centre selection, warehouse operations, sortation, last-mile and tracking. Checkout only needs to authorise payment, reserve inventory and durably create the order with an idempotency key. Everything after that is asynchronous, driven by order events, so a slow warehouse system never blocks a customer. FC selection chooses nodes that meet the promised date at the lowest cost, splitting shipments if needed. Payment is captured on shipment. Each physical hand-off emits a scan event that feeds tracking and notifications. I would design for peaks like Prime Day with load tests, back-pressure on queues and graceful degradation of non-critical features.

The promise service takes the cart items, the delivery pincode and the current time. For each item it finds the nodes holding sellable stock. For each candidate node it adds processing time, the next outbound cutoff, linehaul transit and last-mile capacity at the destination delivery station. The earliest feasible date with spare capacity becomes the promise. To keep it honest, the date is computed from the same inventory and capacity data that fulfilment later uses. The checkout response carries a short-lived promise token, and order creation re-validates it, so a promise that has expired is recomputed and shown again before the customer confirms. I would track promise-kept rate as an input metric and pad the estimate only when data shows systematic misses.

Inventory is reserved, not just read. The reserve call does a conditional update on the SKU and node row: decrement available by the quantity only if available is at least that quantity, using a version check or a single atomic conditional write. Exactly one of the two concurrent requests succeeds. The other gets an out-of-stock result and can try another node or tell the customer. Reads for browsing and the product page can be eventually consistent and cached, because they only inform. The authoritative decision happens at the reservation write. For hot items in a flash sale, I would split a SKU's stock into several buckets so writes spread across partitions, and fall back to other buckets when one runs out.

Authorisation confirms the customer can pay and holds the funds without moving money. Amazon has publicly said it charges when the item ships, so the customer is not charged for something that might be cancelled or go out of stock before dispatch. With split shipments, each shipment's ship event triggers a capture for that shipment's amount, including its share of tax and discounts. The payment service must support multiple partial captures against one authorisation, or else re-authorise per shipment. Holds can expire if a shipment is delayed, so the system tracks hold validity and re-authorises before capture when needed. Each capture uses a key such as shipment ID plus attempt, so a retried ship event never charges twice.

A timeout means the outcome is unknown, not that it failed. Every authorisation request carries an idempotency key tied to the checkout attempt, and the gateway is asked to deduplicate on that key. On timeout I do not blindly retry with a new key. I mark the payment as pending, query the gateway's status API with the same key, and retry with the same key only if the gateway supports idempotent retries. Customer-side double clicks hit the same order idempotency key, so they return the existing order. A reconciliation job compares our ledger with gateway settlement files and automatically voids any orphan authorisations. The customer sees 'payment processing' rather than an error that tempts them to pay again.

Working backwards, as Amazon has publicly described it, means starting with a short press release announcing the finished product to customers, plus an FAQ covering customer and internal questions such as cost, risks and dependencies. If the press release is not exciting or the FAQ exposes a weak customer benefit, you change or stop the idea before building. I would use it to force clarity on who the customer is, what problem we solve and how we will know it worked. The document then becomes the reference during build, so scope debates go back to the customer promise rather than opinions. It pairs naturally with six-page narratives for review meetings.

It means the team that writes a service also operates it in production, including on-call, alarms and incident follow-up. The main effect is incentives: engineers who get paged for flaky deploys invest in tests, safe rollouts, dashboards and automation. It also shortens feedback loops, because operational pain reaches the people who can fix it directly. The cost is that each team needs operational skill and some shared tooling, so I would provide paved roads for deployment, monitoring and runbooks. Combined with small two-pizza teams and API boundaries, it lets teams ship independently. After incidents, a blameless Correction of Error review captures root causes and tracked actions, so learning compounds instead of being lost.

I use the transactional outbox pattern. In one local database transaction, the order service writes the order rows and an outbox row describing the event. A separate relay reads the outbox, or uses change data capture, and publishes to the event stream. It marks rows sent only after the broker acknowledges them. If the relay crashes, it republishes, so delivery is at-least-once. Every event carries the order ID and a sequence number, and consumers deduplicate on the event ID. This avoids a two-phase commit across the database and the broker. It also guarantees that downstream systems, such as inventory, fulfilment and notifications, never see an event for an order that does not exist, and never miss one that does.

Treat it as an optimisation. Find nodes with reserved or reservable stock for each item. Generate candidate plans, single node or split, and filter to those that meet the promise date given cutoffs and capacity. Then pick the lowest total cost, which includes picking, packaging, linehaul, last-mile and the cost of an extra box. Splits are allowed when they are the only way to keep the promise or are clearly cheaper. An exact solve is expensive, so I would use heuristics: prefer the node that covers the most items, and prune distant nodes. I would cap computation time and fall back to a good-enough plan. The plan can be re-run before release to the floor if stock or capacity changed.

Order holds order ID, customer ID, idempotency key, status, address snapshot, promise date and totals. OrderLine holds order ID, line ID, SKU, quantity, price and offer snapshot. Payment holds order ID, method, authorisation reference, status and hold expiry. A Capture table links payment and shipment with an amount and status. Reservation holds SKU, node, quantity, order line and expiry. Shipment holds shipment ID, order ID, node, carrier, tracking ID, status and promised date. ShipmentLine maps order lines to shipments. ScanEvent is append-only, keyed by tracking ID, with type, location, device timestamp and received time. Prices and addresses are snapshotted so later catalogue edits never change a placed order.

I would state assumptions explicitly and derive from them. Start with expected peak orders per second, as a multiple of a normal day's average. Multiply by fan-out: each order generates several reads to price and promise, one authorisation, several inventory writes, and several events. Checkout reads are typically far higher than order writes, because many people browse and check promises without buying. Size the inventory store for the worst hot SKU, not the average, because contention is what breaks. Size the event stream by events per second and retention. Size tracking by parcels multiplied by scans per parcel. Then add headroom, load test at that level beforehand, and pre-scale, because autoscaling reacts too slowly to a sale that starts at a fixed minute.

The pick fails with a reason code, and the node marks that unit unsellable, which corrects inventory. The order line goes back to fulfilment selection, which looks for another node that can still meet the promise date, even at higher cost. Paying more to keep the promise is usually the right trade. If no node can meet the date, the system picks the best alternative, updates the promise, and notifies the customer proactively with the option to cancel. Payment is unaffected until ship, because capture follows the ship event. Metrics on pick failures by node feed the weekly review, because frequent phantom inventory means cycle counts or receiving processes need fixing.

Scanners, sort systems and driver apps emit scan events to an ingestion API. The API validates the device, attaches received time and writes to a durable stream partitioned by tracking ID, so events for one parcel stay ordered in processing. A tracking processor applies events to a per-parcel state machine and updates a read-optimised tracking view, a key-value record per tracking ID that the customer page and notifications read. This is a CQRS split: the write side is an append-only event log, and the read side is a cheap lookup. Notifications fire on meaningful transitions such as shipped, out for delivery and delivered, with dedup. The raw events are kept for audit, disputes and analytics.

Amazon's 2007 Dynamo paper describes exactly this. Being unable to add to the cart loses sales and frustrates customers, so the cart should always accept writes even during partitions. If replicas diverge, the system keeps both versions and merges them, typically as a union of items. The known cost is that a deleted item can occasionally reappear. That is acceptable because the cart is not the source of truth for money or stock. Checkout is where you switch to strong guarantees: the price is recomputed, inventory is reserved with conditional writes, and payment is idempotent. Choosing consistency per step, not per system, is the key point to make in an interview.

A saga. The flow spans services owned by different teams: payment, order, inventory, fulfilment and shipping. These are separated by APIs and run for hours or days, so holding locks across them with two-phase commit is impractical and couples availability. Each step is a local transaction that emits an event. Each step has a compensating action: void the authorisation, release the reservation, cancel the shipment. I would use orchestration for the core order lifecycle, so one service owns the state machine and timeouts and the status is easy to answer. Choreography fits peripheral consumers such as notifications. Every step and compensation must be idempotent, because retries are normal.

The order line has one state machine, and transitions use conditional writes. Cancellation succeeds only if the state is still before 'shipped'. The ship confirm also succeeds only if the line is not cancelled. Whichever write lands first wins. If cancel wins, the warehouse system gets a stop signal, the parcel is pulled before the truck, the reservation is released and the authorisation is voided, so no capture happens. If ship wins, the customer is told it has already shipped and offered refuse-on-delivery or a return, and the capture proceeds normally. The important thing is never to allow both cancel-confirmed and capture.

Amazon has publicly explained that full sentences force clearer thinking than bullet points, because a narrative has to connect claims, reasons and trade-offs. Slides let gaps hide behind formatting and the presenter's delivery. The meeting starts with everyone reading the document silently, so everyone actually has the same context. Discussion then focuses on the hard questions rather than on a presentation. As an engineer, I would write a design doc that way: the customer problem, the tenets, options considered, the proposal, risks and open questions. The appendix holds the data. The cost is writing time, but it is cheaper than a misaligned decision.

The benefits are autonomy and speed. A small team owns a service end to end, can deploy independently, and has a clear owner for every alarm. API-only access, from the well-known early-2000s mandate, stops hidden coupling through shared databases, so teams can change internals freely. The costs are duplication, coordination overhead for cross-cutting changes, and many dependencies that each can fail. A checkout call may fan out to dozens of services. That pushes you toward strong API contracts, versioning, timeouts, fallbacks and dependency dashboards. Someone also has to own the end-to-end experience, such as the delivery promise, even though no single team owns every piece.

Output metrics like revenue or order count are results; the team cannot directly move them. Inputs it can move include in-stock rate for top items and promise accuracy, meaning the share of orders delivered by the promised date. Others are click-to-ship time at each node, pick failure rate, mis-sort rate at sortation, first-attempt delivery success by delivery station, checkout latency at the 99th percentile, payment authorisation success by method, and the double-charge or reconciliation exception count. A good review looks at week-over-week trends and anomalies, asks owners to explain variance, and turns findings into actions. It should also check that each metric's definition is still measuring what we think.

A COE covers the customer impact with data, a timeline, and the detection and response. It asks repeated 'why' questions to reach the root causes, lessons learned, and concrete action items with owners and dates. A good one is blameless: it assumes people acted reasonably given the information they had, and asks why the system let the mistake happen. It also asks why detection was not faster and why the blast radius was that large. Good action items are mechanisms, such as automated checks, alarms or deployment safeguards, rather than 'be more careful'. For example, a double-charge incident should end with an idempotency test in the pipeline, not a reminder email.

Card numbers should never touch most of our services. The checkout page collects card data in a PCI DSS scoped component or via the gateway's hosted fields, and the rest of the system sees only a token. Under RBI card-on-file tokenisation rules, merchants in India cannot store full card numbers for saved cards and must use network or issuer tokens instead. Logs and events must exclude card data and CVV entirely, and should mask other personal data. Payment service access uses least privilege and short-lived credentials, keys live in a managed key service, and the order events carry payment references, not instruments.

Never fake success on payment, because that breaks money guarantees. I would route around failure by method: if one gateway or the card path is failing, keep UPI or other healthy methods available and tell the customer clearly. Use retries with the same idempotency key and backoff, and use circuit breakers so a failing dependency does not exhaust threads. Option to accept the order with payment pending and authorise asynchronously is a business decision: it raises fraud and failed-payment risk, so I would only allow it for low-risk customers and amounts. Everything upstream, like the cart and browsing, should keep working, because it does not need payment.

There is no authorisation, so the order is created with payment pending collection, and the stock is reserved without any funds held. The risk shifts to refusal at the doorstep, which becomes a return-to-origin parcel and costs two-way logistics. Controls include eligibility rules by pincode, order value and customer history, and limits on open pay-on-delivery orders. The driver app records cash or digital collection at the door, and that becomes the payment event. It must still be idempotent, because the app may resend offline. Cash collected by drivers must be reconciled with delivery station deposits. Refused parcels release their reservation back to inventory only after they are received and graded at the node.

UPI confirmation can arrive asynchronously, after the customer approves in their app. I model payment states explicitly: initiated, pending, success, failed. The order is created in a pending-payment state with stock reserved for a short window. Success arrives through the gateway callback or a status poll using the same transaction reference. Both paths go through one idempotent handler, so the order moves to confirmed exactly once. If the window expires without success, the reservation is released and the order is cancelled. If money later shows as debited, reconciliation triggers an automatic refund. The customer screen must say pending clearly, so they do not pay twice.

Driver apps work offline and batch uploads, so order of arrival is not order of occurrence. Each event carries a device timestamp and a per-device sequence number, and is deduplicated by event ID. The state machine only allows forward transitions in its lifecycle, so a late 'out for delivery' event cannot overwrite 'delivered'. It is still stored in the history and shown in the timeline by event time. Clock skew on devices is handled by using the sequence number within a device and server receive time as a tiebreak. Exceptions such as damage or delivery attempted are allowed to move the state sideways, and conflicts are flagged for review rather than silently resolved.

Proof of delivery may include a delivery code, a photo or a geotag. That data is personal, so I collect only what is needed for the dispute window, encrypt it, restrict access by role, and delete it on a defined retention schedule. Live driver location is shown to the customer only near their stop and only while the parcel is out for delivery, not as a full route. Customer phone numbers should be masked through call bridging, so drivers never see raw numbers. In India, this also needs to align with the Digital Personal Data Protection Act's obligations around purpose limitation and consent. Every access to proof-of-delivery photos is logged.

Start with pincode serviceability, because it decides whether a promise is even possible and which delivery station owns the address. Then normalise free text: house, street, locality, landmark. Match it against known delivered addresses and geocodes to suggest corrections, while accepting landmarks because many addresses rely on them. Ask for a pin drop on the map where geocoding confidence is low. I would not block checkout on low confidence. I would flag it so the delivery station can call ahead. Feedback from failed attempts, such as 'address not found', updates the address quality score, so the next order to that address gets a better prompt.

Every reservation has an owner and an expiry. For confirmed orders, the reservation lives until pick. For pending payment, such as a UPI or 3-D Secure flow, it gets a short time-to-live. A sweeper, or a TTL on the reservation record plus an expiry event, releases stock when the window passes without confirmation. Release must be idempotent and conditional on the reservation still being unconsumed, so it never frees a unit that was already picked. I would measure the reserved-but-unconverted ratio, because a TTL that is too long hides sellable stock during a sale, while one that is too short cancels customers who are mid-payment.

I use a STAR structure. For example: our team was asked to build a bulk order export. Instead of starting with the database, I wrote a one-page customer-facing announcement and FAQ and showed it to three account managers. Their questions showed that customers did not want exports at all. They wanted a weekly reconciliation of discrepancies. We changed the scope to an exceptions report, which was smaller to build. Adoption was strong, and support tickets on that topic fell noticeably. The lesson I took was that writing the customer announcement first is the fastest way to discover you are solving the wrong problem. I would quantify results with real numbers from my own experience.

The press release names the customer and the benefit in plain words. For example: shoppers in a listed city can get eligible items the same day if ordered before a cutoff. It says why that matters to them and includes a customer quote. The external FAQ answers which items qualify, the cost, and what happens if the parcel is late. The internal FAQ covers the hard parts: which nodes hold the right selection, last-mile capacity and driver supply, how the promise service avoids overpromising, unit economics, and the risks. If the internal FAQ cannot answer whether we can keep the promise reliably, the project should not start yet.

In the moment, I protect checkout. I use tight timeouts, a circuit breaker, and a fallback where one is safe. For a non-critical call like recommendations, I skip it. For a critical one like the promise, I might use a cached, more conservative estimate rather than fail. Afterwards, I raise it through the owning team's channels with data such as latency charts and call volumes, because they own the fix. Together we agree on an SLA, load-test jointly before the next sale, and consider pre-scaling or caching. If it caused customer impact, it gets a COE. I would not reach into their database or fork their logic; the API is the contract.

I would put alarms on customer-facing symptoms first. These include checkout error rate and latency, authorisation success rate per method, and order creation rate compared with the same time last week, because a drop often signals a silent failure. Then workflow health: orders stuck in one state past a threshold, outbox relay lag, consumer lag on order events, and reservation failures. For money, I would alarm on capture count per shipment greater than one and reconciliation mismatches. For delivery, I would watch parcels with no scan for too long and promise-at-risk counts by station. Each alarm needs an owner, a runbook and a severity, and should page only when it needs human action now.

Use cell-based architecture: split customers or regions into independent cells, each with its own stack, so one bad cell affects a fraction of traffic. Amazon has written publicly about cells and shuffle sharding for this reason. Deployments roll out gradually, one box, then one zone, then one region, with automated rollback on alarm, and bake time between waves. Feature flags separate deploy from release. Business code freezes before major sales reduce risk when stakes are highest. For data changes such as schema migrations, use expand-and-contract, so old and new code both work during the rollout and rollback stays possible.

1. ATransactional outbox with a relay or change data captureCorrect answer
2. BTwo-phase commit between the database and the broker
3. CPublish first, then write to the database
4. DWrite to the database, then publish in a finally block

Why: The outbox row commits atomically with the order, and a relay publishes it at least once, so neither the order nor its event is lost.

1. AAn atomic conditional decrement that succeeds only if enough stock remainsCorrect answer
2. BCheck stock again after payment capture
3. CRead available stock, then write the new value
4. DCache stock in each checkout server

Why: A conditional write lets exactly one concurrent request win, while read-then-write races and lets both succeed.

1. AReject it with a conflict error
2. BCancel the first order and create a new one
3. CCreate a second order
4. DReturn the result of the original requestCorrect answer

Why: Idempotency means the same key returns the same outcome, so retries never create duplicate orders or charges.

1. AAfter delivery is confirmed
2. BWhen the item is added to the cart
3. CWhen the order is placed
4. DWhen the item shipsCorrect answer

Why: Amazon's help pages state that payment is charged when the order ships; checkout only authorises, which also handles split shipments cleanly.

1. ATo list engineering tasks and estimates
2. BTo answer likely customer and internal questions and expose risks before buildingCorrect answer
3. CTo replace the product launch blog post
4. DTo document APIs for other teams

Why: The FAQ tests the idea by answering hard customer and stakeholder questions early, so weak ideas are changed or dropped before engineering effort is spent.

1. AWatch the author present slides
2. BRead the document silentlyCorrect answer
3. CVote on the proposal
4. DReview the code diff

Why: Amazon has publicly described starting meetings with silent reading, so everyone shares the same context before discussion.

1. AA team that has two managers
2. BTwo teams sharing one service
3. CA team rotating on-call every two weeks
4. DA team small enough to be fed by two pizzasCorrect answer

Why: It is a size heuristic: teams small enough to stay fast and own a service end to end.

1. ACorrection of ErrorCorrect answer
2. BChain of Escalation
3. CCentre of Excellence
4. DCost of Engineering

Why: A Correction of Error is Amazon's post-incident analysis with root causes and action items.

1. AShare price
2. BTotal profit
3. CPercentage of orders delivered by the promised dateCorrect answer
4. DQuarterly revenue

Why: Promise accuracy is something the team can directly act on, whereas revenue and profit are outcomes.

1. ACaptured at checkout
2. BCaptured in full when the first shipment ships
3. CCaptured only after both are delivered
4. DCaptured per shipment as each one shipsCorrect answer

Why: Each ship event triggers a capture for that shipment's amount, matching the practice of charging when items ship.

1. AStore the full card number encrypted
2. BStore the card number and CVV
3. CStore a network or issuer token instead of the card numberCorrect answer
4. DAsk the customer to email card details

Why: RBI rules prevent merchants from storing actual card data for saved cards, so tokens are used instead.

1. AStateless with no database
2. BSynchronous
3. CIdempotentCorrect answer
4. DSingle-threaded

Why: Redelivery is expected with at-least-once delivery, so processing the same event twice must have the same effect as once.

1. AChoose the node with the most stock
2. BAlways use the nearest node
3. CAlways ship from a single node
4. DMeet the promise date at the lowest total costCorrect answer

Why: The promise is a constraint, and among feasible plans the lowest total cost, including any split, wins.

1. ACommunicate only through service interfacesCorrect answer
2. BWrite all code in one language
3. CRelease on a single shared schedule
4. DShare one central database

Why: Teams had to expose data and functions only through service interfaces, with no direct database access between them.

1. AKeep the hold until the customer complains
2. BRetry reservation forever
3. CCapture the payment and refund later
4. DVoid or reverse the authorisationCorrect answer

Why: Compensation undoes completed steps, so the hold is released without ever charging the customer.

1. AAfter launch for marketing
2. BBefore building, from the customer's point of viewCorrect answer
3. COnly for AWS products
4. DBy the legal team

Why: The press release and FAQ define the customer value and hard questions before engineering begins.

1. AShowing review counts
2. BBrowsing history
3. CProduct recommendations
4. DInventory reservationCorrect answer

Why: Reservation decides whether a unit is sold, so stale reads there cause overselling, while the others tolerate eventual consistency.

1. AInventory location and network capacity including cutoffsCorrect answer
2. BThe customer's order history only
3. CThe seller's preference
4. DA fixed number of days for every pincode

Why: A promise is only honest if it reflects where stock is and whether processing, transit and last-mile capacity exist.

1. ALock the whole order table
2. BProcess both and refund later
3. CConditional state transitions so only one can winCorrect answer
4. DAlways prefer the ship event

Why: Conditional writes on the order line state ensure the system never confirms a cancellation and also captures payment.

1. ATo encrypt payment data
2. BTo make retries safe so a repeated request does not create a duplicate order or chargeCorrect answer
3. CTo speed up database reads
4. DTo pick the nearest fulfilment centre

Why: Network timeouts cause clients to retry; an idempotency key lets the server return the original result instead of creating a second order or payment.

1. AUse the order ID as the partition keyCorrect answer
2. BUse a single partition for all traffic
3. CUse the timestamp as the key
4. DUse a random partition key

Why: Streams typically guarantee order within a partition, and keying by order ID keeps one order's events together while still scaling across partitions.

1. AUses strong consistency and rejects writes during partitions
2. BStays writable and reconciles divergent versionsCorrect answer
3. CStores carts only in the browser
4. DLocks the cart during checkout

Why: Dynamo prioritised availability for the cart and merged conflicting versions, accepting that deleted items could occasionally reappear.

1. ACreate a second payment request
2. BShip the order immediately
3. CMark it failed and ask the customer to pay again
4. DKeep it pending and confirm through callback or status check under the same referenceCorrect answer

Why: Pending is an unknown outcome, and reconciling under the same reference avoids duplicate debits.

1. AMove back to out for delivery
2. BDelete the delivered event
3. CStay delivered and record the late scan in historyCorrect answer
4. DReset the parcel to in transit

Why: A forward-only state machine prevents late events regressing state, while history still keeps every scan.

1. ACapture anyway
2. BCancel the order automatically
3. CRe-authorise, then captureCorrect answer
4. DSwitch the order to pay-on-delivery

Why: Expired holds may not be capturable, so a fresh authorisation is needed before charging at ship time.

1. ARefusal at the door causing return-to-origin costsCorrect answer
2. B3-D Secure failures
3. CCard chargebacks
4. DAuthorisation hold expiry

Why: With no prepayment, customers can refuse the parcel, creating two-way logistics cost and inventory delay.

1. ALimiting the blast radius of failures to a subset of customersCorrect answer
2. BRemoving the need for monitoring
3. CGuaranteeing zero latency
4. DReducing code size

Why: Independent cells mean a bad deployment or fault affects only the traffic routed to that cell.

1. ADisable reservation for that SKU
2. BSplit its stock into several buckets on different partitionsCorrect answer
3. CIncrease the cache TTL
4. DAllow negative stock

Why: Spreading quantity across buckets spreads writes, and each bucket still uses conditional decrements so stock never goes negative.

1. AMake them public with the tracking link
2. BRestrict access, log views and delete after a retention periodCorrect answer
3. CEmail them to the driver
4. DKeep them forever for analytics

Why: Purpose limitation and least access reduce exposure of personal data while still supporting disputes.

1. AOn-call rotations
2. BUnit tests
3. CCode reviews
4. DSlide decks with bullet pointsCorrect answer

Why: Amazon has publicly said narratives force clearer reasoning than slide-based presentations.

1. AInspects controllable inputs, trends and anomalies with ownersCorrect answer
2. BReviews every line of code
3. CReplaces incident reviews
4. DCelebrates monthly revenue only

Why: WBRs focus on metrics teams can act on and on explaining variances, which drives what to fix next.

1. AQueue capture requests and process them at a controlled rateCorrect answer
2. BDrop excess events
3. CCapture at checkout instead
4. DCall payment synchronously from every scanner

Why: Queue-based load levelling smooths bursts, and idempotent captures make retries from the queue safe.

1. AQuerying the warehouse system directly
2. BAsking the driver app for status
3. CScanning all raw scan events on each request
4. DA precomputed per-parcel tracking view separate from the event logCorrect answer

Why: A CQRS read model turns each page view into a single key lookup, while the event log stays the source of truth.